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, Foreword 

This  report  is  the  second  and  final  report  of  a series  in  the  analysis 
^ of  the  job  of  the  Air  Intercept  Controller  (AIC).  A fully  functional,  work- 

ing model  was  developed  in  order  to  enhance  the  evaluation  of  the  concept  of 
automated  AIC  training  using  computer  speech  recognition,  speech  synthesis, 
and  a computer  model  of  the  instructor.  Hands-on  use  increased  technical 
information  interchange  between  instructional  personnel  and  systems  person- 
nel. The  working  model  provided  a medium  of  communication  between  the 
disciplines  of  computer  science,  education,  and  psychology. 

Heartfelt  thanks  are  extended  to  the  command  and  staff  of  the  Fleet 
Combat  Training  Center,  Pacific,  San  Diego.  LCDR  Cleveland,  OSCS  Billups, 
OSC  Lindsay  and  Mr.  Spencer  proved  invaluable  in  the  refinement  of  the 
functional  specification  for  an  AIC  training  system. 


N AVTRAE QU I PC E N 78-C-0053-1 


TABLE  OF  CONTENTS 


Section 


I INTRODUCTION  5 

Scope 5 

Related  Documents  5 

Document  Organization  5 

II  BACKGROUND  AND  TASK  DESCRIPTION  6 

Background  6 

Objectives  6 

Constraints 6 

Approach  7 

III  THE  SCENARIOS 8 

Brief  Description  8 

Rationale  9 

Scenario  1 — Basic  Intercepts  9 

Scenario  2 — Realistic  Intercepts  10 

Scenario  3 — The  Training  Environment  11 

IV  SYSTEM  DESCRIPTION  15 

Hardware  Description  ...  15 

Menu  Selection/Executive  17 

Simulation 22 

Teaching 34 

Performance  Measurement  and  Evaluation  (PM&E)  ......  36 

V SYSTEM  UTILIZATION  55 

Introduction  55 

Simulation 55 

Teaching 56 

Performance  Measurement  and  Evaluation  57 

Scenario  3 58 

VI  CONCLUSIONS  AND  RECOMMENDATIONS  59 

General  Remarks 59 

Continuing  Research  Interest  59 

Recommended  Training  System  Specifications 60 


( 


3 


NAVTRAEQUI PCEN  78-C-0053-1 


LIST  OF  ILLUSTRATIONS 


Figure  Page 


1 Scenario  3 14 

2 AIC  Laboratory  Hardware  Configuration  16 

3 System  Overview  18 

4 Brief  Scenario  Description  19 

5 System  Utilization  Log  20 

6a  System  Software  Structure  (System  1)  23 

6b  System  Software  Structure  (System  2)  24 

7 Typical  Simulated  NTDS  Display  33 

8 Teaching  Presentation  for  Bogey  Bearing  and  Range  ....  35 

9 Student  Evaluation  Report  38 

10  PMS  File  Organization 45 

11  Prototype  System  Operation  Concept  63 


LIST  OF  TABLES 


_Table  F^j^e. 


1 Scenario  Definition  File 25 

2 Available  Events  to  Trigger  Scenario  Actions  26 

3 AIC  Lab  Phrases  Elements  for  Voice  Synthesis  29 

4 Track  Data  File 30 

5 NTDS  Functions 32 

6 Testable  Options  34 

7 PMTXT  File,  Scenario  2 46 

8 Special  Texts  for  Scenario  2 47 

9 PMEVT2  and  PMEVNT  Files  for  Scenario  2 48 

10  PMDECK  for  Scenario  2 49 

11  PMCLK  File  for  Scenario  2.........  51 

12  PMCHN  File  for  Scenario  2 52 

13  Learning  Objectives  to  be  Addressed  by  AIC-PR0T0.  ....  61 


■ ....  — i — I 


NAVTRAEQUIPCEN  78-C-0053-1 
SECTION  I 
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INTRODUCTION 


SCOPE 


This  document  is  the  final  technical  report  for  the  work  performed 
under  contract  N61 339-78-C-0053 : Air  Intercept  Controller  Front-and 

Analysis.  The  purpose  of  this  project  was  to  identify  instructional 
features  required  for  Air  Intercept  Control  (AIC)  training  and  develop  a 
fully  functioning  model  which  would  validate  the  features  and  provide  a 
basis  of  discussion  on  new  approaches  to  AIC  training.  By  avoiding  the 
pitfalls  of  a "paper-model"  analysis,  the  Government's  intent  was  to  ensure 
the  validity  of  the  instructional  features  of  the  subsequent  experimental 
prototype  AIC  training  system.  This  document,  therefore,  is  intended  for 
use  by  the  Naval  Training  Equipment  Center  and  other  interested  parties  in 
support  of  the  definition,  specification,  and  design  of  the  prototype 
training  system. 

RELATED  DOCUMENTS 


i 

I 


f 


f 


i 


I 

^ L_ 


The  following  documents  describe  work  which  is  related  to  the  efforts 
discussed  herein: 

a . Use  of  Computer  Speech  Understanding  in  Training:  A Demonstration 
Training  System  for  the  Ground  Controlled  Approach  Controller;  Technical 
Report  NAVTRAEQUIPCEN  74-C-0048-1;  Log  icon,  Inc.;  July,  1976. 

b.  Air  Intercept  Controller  Training:  A Preliminary  Review;  Technical 
Report  NAVTRAEQUIPCEN  77-M-1058-I;  Logicon,  Inc.;  June,  1977. 

c.  Speech  Understanding  in  Air  Intercept  Controller  Training  System 
Design;  Technical  Report  NAVTRAEQUIPCEN  78-C-0044-1;  Logicon,  Inc.;  in 
press. 

DOCUMENT  ORGANIZATION 

Following  these  introductory  remarks,  the  report  discusses  in  Section 
II  the  background  against  which  this  study  was  conducted,  and  formulates 
more  precisely  the  problems  addressed  in  the  study.  Section  III  describes 
the  three  scenarios  which  served  as  the  framework  for  the  development  of  the 
laboratory  model.  A more  detailed  discussion  of  that  model,  including  brief 
hardware  and  software  descriptions,  is  presented  in  Section  IV.  The  report 
continues  in  Section  V with  a discussion  of  the  results  uncovered  as  a 
result  of  developing  and  using  the  laboratory  model.  Conclusions  are  drawn 
and  recommendations  made  in  the  final  section  (Section  VI)  of  this  report. 
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SECTION  II 

BACKGROUND  AND  TASK  DESCRIPTION 


BACKGROUND 

The  Demonstration  Training  System  for  the  Ground  Controlled  Approach 
Controller,  NAVTRAEQUIPCEN  74-C-0048-1,  demonstrated  that  advanced  speech 
technologies  and  automated  training  techniques  can  be  successfully  applied 
to  enhance  the  quality  of  instruction  in  controller  training  systems.  Air 
Intercept  Control  (AIC)  training  is  considerably  more  complex  than  GCA 
training,  both  in  the  requirements  of  speech  recognition  and  in  the  learn- 
ing requirements.  The  GCA-CTS  experience  demonstrated  that  the  design  of 
training  systems  can  often  benefit  by  development  of  a laboratory  model  to 
assess  the  technical  and  cost  risks.  Moreover,  a laboratory  system  enables 
a front-end  analysis  using  a fully  functioning  model  not  possible  in  a pure- 
ly paper  analysis. 

OBJECTIVES 

The  objectives  of  this  project  were  fourfold: 

a.  Develop  a system  which  would  facilitate  the  demonstration  of  auto- 
mated controller  training  capabilities  and  act  as  a catalyst  to  promote 
discussion  of  required  functions  among  AIC  instructors,  system  designers, 
and  research  psychologists. 

b.  Provide  a pseudo-training  environment  for  evaluation  of  instruc- 
tional strategies  and  skill  assessment  techniques  by  automated  performance 
measurement  technology. 

c.  Provide  a test-bed  for  new  algorithms  for  automatic  computer  speech 
recognition,  so  that  high  risk  areas  can  be  identified  early  in  the  proto- 
type development  effort. 

d.  Determine  the  requirements,  investigate  design  alternatives,  and 
estimate  the  implementation  costs  for  the  simulation  needed  to  support  AIC 
training. 

CONSTRAINTS 

This  project  was  constrained  by  a number  of  factors  including  hardware 
selection,  speech  technology  to  be  addressed,  and  extent  syllabus  automation 
was  to  be  examined.  The  hardware  suite  upon  which  the  model  was  to  be 
developed  and  exercised  is  the  system  concurrently  supporting  the  GCA-CTS 
experimental  prototype.  Briefly,  this  includes  two  Data  General  Eclipse 
computers,  a 10  MByte  disc,  a Megatek  MG552  display,  two  CRTs,  a Tally  high- 
speed character  printer,  a Votrax  speech  synthesizer,  and  a Threshold  Tech- 
nology voice  input  preprocessor. 
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The  development  effort  was  also  constrained  by  the  speech  technology  to 
be  studied,  namely  Limited  Continuous  Speech  Recognition  (LCSR).  The  devel- 
opment of  a speech  understanding  subsystem  for  use  in  AIC  training  was  the 
subject  of  a parallel  effort  and  is  described  more  fully  in  NAVTRAEQUIPCEN 
7 8-C-0044-1 . 

Finally,  the  laboratory  model  specifically  did  not  address  the  automa- 
tion of  the  training  syllabus,  since  this  issue  was  considered  to  be  similar 
in  concept  to  the  automated  syllabus  functions  being  implemented  in  the  GCA- 
CTS.  Specific  elements  within  a functional  syllabus  were  implemented,  but 
no  attempt  was  made  to  weave  these  elements  together  into  a structural 
whole.  However,  the  development  of  an  effective  performance  measurement 
subsystem,  which  was  studied  in  this  effort,  is  a necessary  prerequisite  to 
the  functions  of  automated  evaluation  and,  then,  syllabus  control. 

APPROACH 

The  technical  approach  toward  satisfying  the  objectives  of  this  study 
was  to : 

a.  Define  three  scenarios  which  represented  a sufficiently  generalized 
set  of  AIC  tasks. 

b.  Conceptualize  a laboratory  model  which  would  provide  the  demonstra- 
tion and  research  vehicle  for  studying  the  simulation  and  training 
issues . 

c.  Based  upon  the  AIC  scenarios  and  the  model's  general  structure,  de- 
fine in  more  specific  detail  the  scenario  components  and  the  system  func- 
tions they  imply. 

d.  Design,  implement,  and  test  the  software  needed  to  support  the 
identified  functions  of  the  laboratory  model. 

e.  Expose  Fleet  Combat  Training  Center  and  Naval  Training  Equipment 
Center  personnel  to  the  model,  and  gather  feedback  on  its  technical  and 
instructional  features. 

f.  Prepare  this  final  report  summarizing  the  lessons  learned  through 
the  development  and  utilization  of  the  system. 

It  should  be  emphasized  here  that  the  AIC  laboratory  model  is  viewed  as 
a very  powerful  tool  for  the  continued  test  and  refinement  of  various  AIC 
training  system  features.  The  initial  exposure  of  the  AIC  prototype  devel- 
opers reported  herein  is  only  the  first  of  many  experiences  with  the  system 
as  it  evolves. 
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SECTION  III 
THE  SCENARIOS 

The  principal  vehicle  for  the  specification  and  design  of  the  AIC 
laboratory  model  has  been  three  scenarios  which  encompass  important  control- 
ler job  responsibilities.  This  section  describes  these  scenarios  and  their 
related  learning  objectives,  and  also  presents  the  rationale  for  their 
selec  tion. 

BRIEF  DESCRIPTION 

The  following  paragraphs  provide  a brief  overview  of  the  three  sce- 
narios in  order  to  familiarize  the  reader  with  their  general  functional 
characteristics,  and  to  provide  a preliminary  framework  in  which  to  describe 
the  rationale  for  their  selection. 

BASIC  INTERCEPTS.  Scenario  1 addresses  the  basic  tasks  which  the  AIC  must 
perform  in  conducting  a simple  intercept.  As  the  exercise  unfolds,  the  AIC 
must  locate  his  assigned  aircraft  and  establish  radio  contact  with  the 
pilot.  When  a bogey  (hostile  aircraft)  is  detected,  the  AIC  communicates 
with  the  pilot  to  vector  him  to  a nearest  collision  intercept.  As  the  exer- 
cise proceeds,  the  controller  must  regularly  and  accurately  provide  informa- 
tion to  the  pilot  concerning  the  bogey's  bearing,  range,  track,  and  ground 
speed.  Scenario  1 concludes  when  the  friendly,  controlled  aircraft  comes 
into  radar  contact  with  the  hostile  aircraft. 

REALISTIC  INTERCEPTS.  Scenario  2 builds  upon  the  basic  structure  of 
Scenario  1,  adding  several  complications  that  more  nearly  represent  actual 
air  intercepts.  In  addition  to  providing  bogey  position  and  velocity  up- 
dates, the  controller  must  now  also  detect  and  report  any  sudden  changes  in 
the  bogey's  heading,  and  recommend  new  vectors  to  accommodate  the  maneuver- 
ing hostile  aircraft.  Moreover,  the  AIC  must  detect  the  presence  and  report 
the  range,  bearing,  track  and  groundspeed  of  other  aircraft  in  the  vicinity 
of  the  controlled  aircraft.  Finally,  the  AIC  must  respond  to  communications 
from  the  ;,ilot  at  the  point  of  radar  contact,  at  the  time  when  the  pilot 
takes  over  the  intercept  himself,  and  when  the  pilot  loses  contact  with  the 
bogey  and  needs  additional  position,  velocity,  and  vectoring  information. 

THE  TRAINING  ENVIRONMENT.  In  addition  to  learning  to  control  aircraft  in 
combat-like  intercept  conditions,  the  controller  is  often  called  upon  to 
assist  in  pilot  training  by  setting  up  mock  intercepts  in  well-established 
training  areas.  Scenario  3 commences  with  two  aircraft  flying  in  formation 
toward  the  training  area.  The  AIC  makes  radar  contact  with  the  two  aircraft 
and  establishes  a lost  communications  procedure  with  the  pilots.  The  AIC 
recommends  vectors  to  the  aircraft  for  area  control  and  maintains  the  air- 
craft in  the  area  by  providing  heading  advisories.  The  AIC  then  detaches 
one  aircraft  (the  bogey)  and  turns  the  other  aircraft  (interceptor)  for 
separation.  The  controller  determines  a planning  bearing,  target  aspect 
angle,  and  track  crossing  angle  based  upon  the  point  at  which  he  desires  the 


intercept  to  take  place.  After  getting  the  proper  separation,  the  AIC  turns 
the  aircraft  for  the  mock  intercept  and  Scenario  3 continues  as  described  in 
Scenario  2.  When  the  aircraft  merge,  the  AIC  provides  breakaway  headings 
and  Scenario  3 concludes  as  the  two  aircraft  separate. 

RATIONALE 

The  selection  of  the  model's  scenarios  was  guided  by  the  following 
considerations . 

a.  The  chosen  scenarios  should  include  a reasonably  complete  exercise 
of  the  speech  technologies  needed  to  support  AIC  training.  These  technolo- 
gies included  isolated  word,  or  phrase,  recognition;  limited  vocabulary  con- 
nected speech  recognition;  and  computer  voice  synthesis. 

b.  The  chosen  scenarios  should  include  the  most  critical  training 
areas,  and  hence  stimulate  the  interest  of  AIC  instructors. 

c.  The  chosen  scenarios  should  not  be  too  demanding  upon  the  simu- 
lation requirements  that  they  impose.  The  resulting  system  must  be  imple- 
mentable  on  the  provided  hardware  configuration. 

d.  The  chosen  scenarios  should  be  sufficiently  generalized  to  rep- 
resent a cross  section  of  typical  AIC  training  environments  in  order  to 
provide  validity  to  technical  and  cost  estimates  based  upon  experience  with 
the  laboratory  model. 


As  will  be  demonstrated  when  they  are  described  in  detail  in  the  fol- 
lowing subsections,  the  chosen  scenarios  satisfy  each  of  these  criteria. 

SCENARIO  1 - BASIC  INTERCEPTS 

Scenario  1 encompasses  four  learning  objectives:  check-in  procedures, 
vectors  for  bogey,  bogey  bearing  and  range  reports,  and  bogey  track  and 
ground  speed  reports.  These  objectives  represent  basic  tasks  which  the  AIC 
will  routinely  perform.  Scenario  1 provides  an  environment  in  which  these 
tasks  and  their  corresponding  skills  can  be  taught  and  practiced. 

When  the  intercept  begins,  the  range  scale  is  at  64  mifes,  ownshlp  is 
off  center  to  the  east,  and  the  Combat  Air  Patrol's  (CAP's)  video  (radar 
presentation)  and  friendly  symbol  are  in  orbit  approximately  15  miles  from 
ownship.  The  symbol  is  being  kept  on  its  video  via  a simulated  tracker. 
The  CAP's  call  sign  is  the  tactical  call  of  Snake.  The  CAP  is  squawking  a 
Mode  2 code  of  5201. 


( ) 


The  AIC's  first  responsibility  is  to  go  through  the  check-in  procedures 
with  the  CAP.  This  includes  locating  the  aircraft  by  challenging  the  video 
until  the  established  Identification  Friend  or  Foe  (IFF)  code  (5201)  is 
returned.  Next,  a CAP  symbol  is  built;  this  informs  the  Naval  Tactical  Data 
System  (NTDS)  that  this  is  the  aircraft  which  this  AIC  will  control.  To  do 


[ 
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this,  che  trainee  will  hook  Che  friendly  symbol;  will  enter  the  aircraft's 
Mode  2 code,  the  data-link  address,  and  the  link  status;  will  observe  an 
"FA"  symbol  near  ownship;  and  will  depress  ORDER-SEND.  The  friendly  symbol 
then  change:  to  a CAP  symbol  and  is  removed  from  command  tracking.  From 
this  point  on,  the  AIC  is  responsible  for  keeping  the  symbol  on  the  video. 
The  final  step  in  the  check-in  procedures  is  to  conduct  the  radio  check: 
"Snake,  radio  check,  over."  The  pilot  responds,  "Snake  is  in  a port  (star- 
board) orbit,  angels  twenty,  ready  for  control." 

Shortly  after  completing  the  check-in  procedures,  a hostile  aircraft 
(video  and  tracked  symbol)  appears  from  the  west.  The  AIC  uses  NTDS  to 
determine  a recommended  nearest  collision  intercept  geometry.  Based  upon 
the  computed  vector  (XXX),  the  AIC  transmits  to  the  CAP,  "Snake,  vector  XXX 
for  bogey."  The  pilot  responds,  "Roger,  vector  XXX." 

In  this,  Scenario  1,  the  bogey  continues  on  his  original  course,  and 
the  CAP  is  turned  to  command  heading.  The  CAP  and  bogey  are  engaged,  and 
the  AIC  must  utilize  the  appropriate  NTDS  functions  to  determine  the  bearing 
and  range  from  the  CAP  to  the  bogey,  and  to  determine  the  bogey's  track  and 
ground  speed.  (Altitude  is  not  addressed  in  this  model.)  These  advisories 
are,  in  turn,  transmitted  to  the  CAP:  "Bogey  XXX, YY"  and  "Bogey  tracking 

XXX,  speed  point  X."  When  the  CAP  receives  contact,  the  scenario  ends. 

SCENARIO  2 - REALISTIC  INTERCEPTS 

Scenario  2 builds  upon  the  basic  jobs  presented  in  Scenario  1 and  adds 
the  following  three  learning  objectives:  report  strangers  in  the  vicinity 

of  the  CAP,  respond  to  a course  jink  by  the  bogey  (a  jink  is  a drastic 
change  in  direction),  and  respond  to  various  pilot  initiated 
communications . 

The  scenario  is  very  similar  to  Scenario  1 until  the  tracks  are  engag- 
ed. At  this  point,  strangers  — or  unknown  aircraft  ~ enter  the  area.  The 
AIC  must  report  bearing,  range,  track  and  ground  speed  information  to  the 
CAP  until  the  pilot  indicates  he  has  visual  contact  with  the  unknown  air- 
craft, or  until  the  stranger  opens  relative  to  the  CAP. 

Moreover,  whereas  in  Scenario  1 the  bogey  never  changes  his  direction, 
in  Scenario  2 the  hostile  aircraft  changes  its  heading  while  the  CAP  is 
engaged  to  it.  The  AIC  must  detect  the  jink,  and  report  to  the  pilot: 
"Bogey  jinking  lef t/ right ...  Snake , vector  XXX."  As  before,  the  recommended 
heading  to  counter  the  jink  is  provided  by  NTDS. 

Finally,  the  AIC  must  respond  to  pilot  initiated  transmissions.  Recall 
that  Scenario  1 ended  as  the  CAP  obtained  a contact.  At  this  point  in 
Scenario  2,  the  pilot  gives  a contact  call:  "Contact,  XXX, YY.’"  The  AIC 
must  confirm  chat  the  pilot  is  reporting  on  the  correct  aircraft,  and  he 
must  respond  accordingly:  "Roger,  that  is  your  bogey"  or  "Negative,  your 

bogey  XXX, YY."  The  controller  continues  to  give  "bogey  dope"  (position, 
track  and  speed  information)  until  the  pilot  calls,  "Judy,"  which  indicates 
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he  has  contact  with  the  hostile  aircraft  and  has  taken  control  of  the  inter- 
cept. The  A1C  ceases  giving  "bogey  dope”  while  staying  alert  for  jinks  or 
"lost  contact"  calls  from  the  pilot,  at  which  points  the  A1C  would  start 
relaying  advisories  to  the  CAP  again.  Finally,  the  pilot  will  call,  "Fox  1" 
or  "Fox  2,"  indicating  he  fired  his  missiles,  and  Scenario  2 ends. 

SCENARIO  3 - THE  TRAINING  ENVIRONMENT 

Scenario  3 addresses  an  ancillary  job  of  the  AIC:  assisting  in  pilot 
training  using  mock  intercepts.  The  learning  objectives  of  this  scenario 
include : 


a.  Pick  up  assigned  aircraft. 

b.  Determine  lost  communications  protocol. 

c.  Determine  planning  bearing,  target  aspect  angle,  angles  off,  and 
track  crossing  angle. 

d.  Plot  CAP's  heading,  and  bogey's  heading  and  reciprocal. 

e.  Establish  an  intercept  area  and  turn  aircraft  accordingly. 

f.  Determine  headings  for  breakaways  and  area  control. 

At  exercise  initiation,  ownship  is  off-center  and  two  friendly  aircraft 
(symbols  and  video)  are  in  orbit  approximately  20  miles  from  ownship.  The 
tactical  call-signs  are  Snake  and  Viper.  Snake  is  the  leader  and  will  be 
the  CAP;  Viper  is  flying  with  Snake  and  will  be  the  bogey.  The  training 
area  is  outlined  on  the  screen. 

The  AIC  conducts  a radio  check  with  both  aircraft,  locates  the  air- 
craft, and  builds  the  CAP  symbols.  The  controller  then  vectors  the  aircraft 
to  the  center  of  the  operating  area:  "Snake,  port  (starboard)  XXX  for  the 
area." 


To  establish  the  lost  communication  procedure  the  AIC  transmits, 
"Snake,  say  lost  conunicat ions  intentions,  over."  The  pilot  responds,  "This 
is  Snake,  point  whiskey,  twenty,  port  orbit.”  The  AIC  will  determine  if  any 
firing  exercises  or  other  aircraft  will  intervene  the  aircraft's  transit 
from  the  control  area  to  the  rendezvous  point.  If  no  problems  are  foreseen, 
the  AIC  transmits,  "Roger,  out";  otherwise  the  AIC  would  recommend  another 
rendezvous:  "Tango  1,  Tango  2 hot,  recommend  rendezvous  Point  Sierra.” 

When  the  aircraft  are  about  five  miles  from  the  center  of  the  area,  the 
AIC  will  detach  the  aircraft  by  assigning  diverging  courses  for  the  bogey 
and  CAP.  The  AIC  will  transmit,  "Viper,  detach  starboard  XXX,"  and  the 
bogey  pilot  will  respond,  "Viper,  roger,  starboard  XXX."  To  the  CAP,  the 
AIC  will  transmit,  "Snake,  port  XXX,"  with  the  response  from  the  CAP  pilot, 
"Snake,  roger,  port  XXX."  The  directions  of  turns  and  assigned  headings 
place  the  aircraft  on  reciprocal  headings  for  opening  the  range  and 
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positioning  them  within  the  assigned  operating  area  at  points  from  which 
their  next  tarns  will  commence  the  initial  intercept. 

While  the  bogey  and  CAP  are  opening,  the  AIC  will  solve  a problem  in 
intercept  geometry.  The  "given"  or  "measured"  information  includes  the 
general  direction  for  the  intercept  (to  which  side  of  the  line  between  the 
aircraft),  the  range  separation  from  which  the  intercept  will  be  initiated, 
the  (equal)  speeds  of  the  aircraft,  and  the  angular  relationship  between 
bogey  and  CAP  heading  at  which  the  intercept  is  to  be  made.  With  this 
information,  the  AIC  computes  the  next  headings  to  be  transmitted  to  the 
bogey  and  CAP;  the  turns  will  convert  the  two  opening  aircraft  into  closing 
opponents  for  the  intercept.  The  solution  introduces  terms  which  are  defin- 
ed as  follows: 


Planning  Bearing  (0): 


Magnetic  bearing  from  CAP  to  bogey,  pro- 
jected between  the  points  from  which  both 
aircraft  will  be  turned  (when  desired 
range  is  reached)  to  initiate  the  inter- 
cept. If  there  is  any  bearing  drift 
while  the  aircraft  are  opening,  planning 
bearing  is  taken  to  the  next  5 degrees  in 
the  direction  of  drift. 


Target  Aspect  Angle  (TAA): 


Angle  Off  (AO): 


CAP  Heading  (F): 


Bogey  Heading  (B): 


The  angle  measure  between  the  bogey's 
track  and  the  line  of  sight  to  the  CAP, 
or  how  the  bogey  looks  at  the  CAP.  The 
angular  difference  measured  from  bogey 
heading  to  the  line  of  sight  to  the  CAP. 
Also,  the  angular  difference  measured 
between  the  extended  bearing  line  from 
the  CAP  to  the  bogey  (0),  measured  to  the 
reciprocal  (R)  of  the  bogey  track  (B). 

The  angle  measure  between  the  CAP's  track 
and  the  line  of  sight  to  the  bogey,  or 
how  the  bogey  looks  from  the  CAP.  The 
angular  difference  between  the  CAP  head- 
ing (F)  and  the  bearing  from  the  CAP  to 
the  bogey  (0). 

The  magnetic  heading  of  the  CAP  during 
intercept . 

The  magnetic  heading  of  the  bogey  during 
intercept . 


Bogey  Heading  Reciprocal  (R): 


The  reciprocal  of  the  bogey  heading. 


In  this  training  environment,  the  AIC  is  calculating  intercept  courses  for  a 
"collision,"  with  two  aircraft  at  equal  speed.  This  produces  an  intercept 
with  equal  angle  measures  for  TAA  and  AO,  with  a steady  (constant)  bearing 
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from  CAP  to  bogey  equal  to  0.  Figure  l presents  an  example  of  a geograph- 
ical plot  of  the  two  aircraft  approaching  the  area,  turning  for  opening,  and 
turning  for  intercept.  Also  presented  is  a simulated  scope  presentation 
showing  projections  of  the  bearings  and  tracks  as  the  AIC  would  compute 
values  for  the  intercept.  Note  that  the  plot  and  scope  presentation  are 

based  on  magnetic  bearings  and  courses  which  the  AIC  uses  after  applying  the 
correction  for  magnetic  variation  15  degrees  East. 

To  calculate  for  the  depicted  intercept,  the  AIC  will  mark  planning 

bearing  on  the  scope  (345),  add  angle  off  (30)  in  the  direction  the  inter- 
cept is  to  take  place,  and  mark  "F"  on  the  scope  for  fighter  head  (315).  He 

will  apply  the  same  number  of  degrees  as  AO  (TAA)  in  the  opposite  direction 
from  0,  and  mark  "R"  on  the  scope  for  reciprocal  of  bogey  heading.  The  AIC 
then  will  take  the  reciprocal  of  "R”  and  plot  "B”  for  bogey  head.  After 

getting  the  proper  separation,  the  AIC  turns  the  bogey.  AIC  transmits, 

"Viper,  port  195  as  bogey";  the  bogey  pilot  responds,  "Viper,  roger,  port 
195  as  bogey."  The  AIC  then  turns  the  interceptor,  "Snake,  starboard  315 
for  bogey,"  and  the  CAP  pilot  responds,  "Snake,  roger,  starboard  315."  The 
intercept  continues  as  in  the  other  scenarios. 

When  the  plots  of  the  two  aircraft  merge,  the  AIC  will  give  breakaway 

headings,  "Viper,  port  XXX  for  breakaway,"  and  the  pilot  responds,  "Viper, 

roger,  port  XXX  for  breakaway."  The  AIC  transmits,  "Snake,  continue  XXX,” 
and  the  pilot  transmits,  "Snake,  roger,  continue  XXX."  As  the  two  aircraft 
separate,  the  scenario  ends. 
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SECTION  IV 


SYSTEM  DESCRIPTION 


The  AIC  laboratory  model  (AIC-LAB)  can  be  organized  around  four  areas. 
This  division  proved  to  be  a useful  artifice  for  the  program  development 
effort,  and  will  also  facilitate  discussion  of  the  functional  characteris- 
tics and  hardware/sof tware  design  of  the  system.  These  areas  are: 

a.  An  Executive  program,  which  facilitates  the  demonstration  of 
implemented  model  capabilities 

b.  AIC  Simulation  programs,  which  provide  the  overall  environment  for 
the  following  two  areas 


c.  Performance  Measurement  and  Evaluation  (PM&E)  programs,  which  moni- 
tor the  AIC's  performance  and  provide  feedback  on  specific  errors  and/or 
overall  strengths  and  weaknesses 

d.  Teaching  programs,  which  lead  the  AIC  through  the  various  learning 
objectives  and  instruct  him  on  the  requisite  skills 


HARDWARE  DESCRIPTION 

A block  diagram  of  the  hardware  used  to  support  this  AIC  laboratory 
model  is  shown  in  Figure  2.  This  hardware  included: 

a.  Computers  (2):  Data  General  Eclipse  S/130 

CPU-1:  64K  Semi-conductor  memory 

CPU-2:  96K  Semi-conductor  memory 

b.  Disk  (1):  Data  General  6045  Disk  Drive 

c.  System  Console  (2):  Data  General  6053  Display  Terminals 

d.  IPB  (1):  Data  General  4240  Inter-Processor  Bus 

e.  Graphics  Display  (1):  Megatek  MG552  Graphics  Display 

f.  Joystick  (1):  Megatek  Joy-3  75882 

g.  Speech  Synthesizer  (1):  Votrax  VS-6.4  Audio  Response  System 

h.  Voice  Input  Preprocessor  (I):  Threshold  Technology  500 

i.  Line  Printer  (1):  Tally  T1602  Printer 

j.  Microphone  (1):  Shure  SM10 

k.  Speaker  (1):  Radio  Shack 


SPEECH  I , VOICE  INPUT 

SYNTHESIZER  I PREPROCESSOR 
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MENU  SELECTION/EXECUTIVE  (MS/E) 

MS/E  is  the  program  activated  by  the  operating  system.  The  purposes  of 
the  program  include: 

a.  Communicating  with  the  user  to  activate  the  specific  AIC-LAB  func- 
tion desired 

b.  Facilitating  demonstration  of  the  AIC-LAB  system  by  presenting 
overviews  of  the  system  and  the  scenarios 

c.  Suggesting  automated  record-handling  capabilities  by  producing  a 
system/user  utilization  log  upon  user  request 

d.  Establishing  synchronization  of  the  two  Eclipse  computers 

e.  Swapping  the  proper  save  files  into  core  for  execution  of  requested 
functions 

The  MS/E  program  actually  consists  of  two  programs.  The  primary  pro- 
gram resides  in  CPU-1;  a smaller  secondary  program  resides  in  CPU-2,  the 
main  functions  of  which  are  the  last  two  items  mentioned  above. 

The  following  describes  the  functions  and  designs  of  the  MS/E  in  CPU-1. 
The  user  enters  his  name  at  CRT-1 . MS/E  validates  that  the  user  files  exist 
(voice  data,  performance  data,  and  the  utilization  log).  Except  for  the 
voice  data  files,  new  files  are  created  if  necessary.  The  Operations  Menu 
is  presented  on  CRT-1 : 


1 — System  Overview 

2 — Scenario  Descriptions  (brief) 

3 ~ System  Utilization  Report 

4 — Voice  Data  Validation 

5 — Scenario  Selection 

6 — Return  to  CLI 


The  user  types  the  number  associated  with  the  desired  option  (followed 
by  a carriage  return).  Invalid  entries  are  ignored.  Valid  entries  and 
their  resultant  actions  are: 

1 — Simple  text  is  sent  to  CRT-1  describing  the  purpose  of  the  AIC-LAB 

system.  (See  Figure  3.)  MS/E  pauses  until  the  user  strikes  any 
key,  at  which  time  the  Operations  Menu  is  represented. 

2 — Simple  text  is  presented  describing  in  general  terms  the  three 

basic  scenarios.  (See  Figure  4.) 

3 “ Read  the  user's  system  utilization  file  from  the  disc  and  format  a 

report  such  as  that  shown  in  Figure  5. 
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Figure  4.  Brief  Scenario  Description 
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4 -Update  the  user's  system  utilization  file  to  indicate  voice 

validation  usage.  Swap  the  Voice  Validation  program  into  CPU-2, 
and  wait  for  a code  to  indicate  termination  of  the  validation 
process.  Update  the  log  file  with  sign-off  time  and  clear  abort 
flag.  Return  to  the  Operations  Menu. 

5 ~ Request  the  user  to  specify  the  desired  scenario  (1,2,3).  Validate 

that  a Scenario  Definition  File  exists  for  the  chosen  scenario. 
Create  a temporary  communications  file  and  write  the  user's  name 
and  the  chosen  scenario  number  on  that  file.  Display  the  Function 
Menu  (see  below). 

6 — Return  to  the  Operating  System. 

The  Function  Menu  presents  the  user  with  options  to  the  scenarios 
themselves : 

1 — Scenario  Description  (detailed) 

2 ~ Teaching  and  Remediation 

3 “ Freeze  and  Feedback 

4 — Practice 

5 — Operations  Menu 

The  user  will  type  the  number  associated  with  the  desired  option. 
Invalid  entries  are  ignored.  Valid  entries  and  their  actions  are: 

1 — Simple  text  is  presented  describing  the  scenario  in  moderate 

detail.  Pause.  Return  to  the  Function  Menu. 

2 ~ A list  of  learning  objectives  for  this  scenario  are  presented  and 

the  user  indicates  (by  number  entry)  the  objective  for  which  he 
desires  teaching  presentation.  This  information  is  written  into 
the  temporary  disk  file  to  communicate  with  other  save  files.  The 
user's  system  utilization  file  is  updated  to  Indicate  his  request. 
Send  a code  to  CPU-2  to  notify  the  MS/E  in  CPU-2  to  load  the  teach- 
ing program  on  that  side.  Wait  for  code  from  CPU-2  indicating 
proper  load.  Swap  in  the  teaching  program  on  this  side.  When 
control  is  returned,  wait  for  a code  from  CPU-2  to  indicate  MS/E  is 
back  in  control  on  that  side.  Update  the  system  utilization  file 
with  sign-off  time.  Return  to  the  Function  Menu. 

3 ~ MS/E  presents  an  all-inclusive  list  of  learning  objectives  (e.g., 

Scenario  2 would  include  calling  range  and  bearing).  It  requests 
the  user  to  indicate  those  for  which  he  wants  to  freeze  on  errors 
and  be  given  feedback  and  then  proceeds  as  above  (save  in  temporary 
file,  update  utilization  file,  load/release  programs,  update  utili- 
zation file,  and  return  to  the  Function  Menu.) 

4 — No  options  are  given  to  the  user.  The  MS/E  proceeds  immediately 

with  the  (by  now)  familiar  sequence  detailed  above. 
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5 — Delete  the  temporary  communications  file  and  return  to  the  Opera- 
tions Menu. 

The  portion  of  MS/E  which  resides  in  CPU-2  simply  waits  for  the  load 
codes  from  CPU-1,  and  loads  the  proper  program  (which  will  send  the  confirm- 
ation code).  When  control  is  returned,  MS/E  sends  an  "all  done"  code  to 
CPU-1  and  goes  back  waiting  for  another  input. 

SIMULATION 

The  simulation  programs  of  the  AIC  model  are  common  to  PM&E  and  Teach- 
ing. (See  Figures  6a  and  6b.)  They  include: 

a.  Basic  Scenario  Control  (BSC) 

b.  Pilot  Model 

c.  Aircraft  Model 

d.  Radar  Simulation 

e.  NTDS  Simulation 

f.  Speech  Recognition 

Each  of  these  except  the  last  is  discussed  from  a functional/design 
perspective  in  the  following  paragraphs.  Speech  Recognition  is  the  subject 
of  a companion  report  cited  earlier,  NAVTRAEQUIPCEN  78-C-0044-1. 

BASIC  SCENARIO  CONTROL.  BSC  performs  three  major  functions: 

a.  Set  up  scenario  conditions  using  time-  and  event-tagged  entries  in 
the  Scenario  Definition  File 

b.  As  the  MAIN  routine  in  each  computer,  orchestrate  the  other  AIC 
subsystems  by: 

(1)  Calling  major  routines 

(2)  Activating,  suspending,  and  killing  tasks 

(3)  Coordinating  communications  between  the  computers  via  the  IPB 

c.  Interface  with  the  AIC-LAB  user  to  freeze,  continue  (proceed),  and 
abort  exercises. 

Scenario  Generation.  Scenarios  are  controlled  via  formatted  card  image 
lnpuc.  The  cards  may  indicate  either  event-initiated  actions  or  time- 
initiated  actions.  These  actions  generate  tracks,  drop  tracks  and  modify 
the  motion  of  the  tracks.  The  format  of  the  entries  in  the  scenario  defini- 
tion file  (SDF.YX  where  X-l , 2,  or  3 and  Y ■ a version  identifier)  is  shown 
in  Table  1.  Events  which  can  initiate  scenario  functions  are  presented  in 
Table  2.  The  software  design  of  the  scenario  generation  portions  of  BSC 


6a.  System  Software  Structure  (System  1) 


TEACHING 


tem  Software  Structure  (System  2) 
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TABLE  l.  SCENARIO  DEFINITION  FILE 


Scenario  ID 

cc  1-80  Descriptive  text 

Default  Conditions 


cc 

1-3 

Standard  turn  rate  (degrees/ sec) 

cc 

11-13 

Hard  turn  rate 

cc 

21-23 

Slow  turn  rate 

Create 

CC 

Track 

1 

1 

cc 

6-7 

track  number 

cc 

11-13 

1 = ownship 

2 = CAP  convention 

3 » bogey 

4 = stranger  (if  any) 

time  (sec)  from  start  of  exercise,  or  — if 

cc 

21 

negative  ““  event  number 
track  type: 

cc 

26-27 

0 = unused  track;  only  in  track-data  file) 

1 = ownship 

2 = CAP 

3 = bogey 

4 = stranger 

5 = friendly 

6 = other 

radius  (miles)  initial  position  with  resnec 

cc 

31-33 

bearing  center  of  screen 

cc 

36-39 

speeu  (uiiles/hr) 

cc 

41-43 

heading 

cc 

46 

motion  model 

cc 

51-53 

1 = simple 

2 = turning 

3 = orbit 

4 - stationary 

directed  heading  (if  turning) 

cc 

56-58 

turn  rate  (deg/sec;  if  turning) 

cc 

61-65 

IFF  code  (4  or  5 digits;  0 = if  not  friendly) 

cc 

71-72 

altitude '( thousands  of  feet) 

Drop  Track 
cc  1 

2 

CC 

2-13 

same  as  above 

Modify  Dynamics 
cc  1 

3 

CC 

2-13 

same  as  above 

cc 

21 

new  motion  model 

cc 

26-28 

turn  rate  (if  new  motion  is  turning  or  orbit) 

cc 

31-33 

directed  heading  (if  turning) 

TABLE  2.  AVAILABLE  EVENTS  TO  TRIGGER  SCENARIO  ACTIONS 
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include  the  following  routines  (the  names  of  the  routines  appear  in  capital 
letters) : 


a.  AIRINIT  reads  in  all  SDF.YX  cards  which  represent  event- initiated 
actions  into  a buffer,  and  their  corresponding  events  into  array  TRGEVT. 

b.  BSCEVENT  upon  the  occurrence  of  an  event  does  a binary  seach  in 
TRGEVT  for  that  event.  If  it  is  found,  its  SDF  "card"  is  pulled  out  of  the 
buffer  and  executed. 

c.  BSCPER  checks  the  present  time  (ICLOCK)  every  second  to  see  if  it 
is  equal  to  the  time-intiated  actions  in  the  SDF.YX  file.  If  it  is,  that 
"card”  is  executed  and  the  next  "card"  is  read  in. 

d.  BSCACT  executes  the  SDF  cards.  It  determines  which  action  to  take 
(create  a track,  drop  a track  or  modify  dynamics)  and  calls  the  appropriate 
subroutines. 

e.  CTLTRAC  creates  a new  track  in  the  Track  Data  File  (TDF). 

f.  CTLTRAC  creates  a new  track  from  TDF. 

Inter-processor  Communications.  Communication  between  the  two  computers  is 
accomplished  with  binary  writes  across  the  Inter-processor  Bus  (IPB).  Each 
system  has  a listening  task  whose  only  job  is  to  receive  messages  sent  to 
its  system.  Any  routine  can  write  Information  should  it  need  to  communicate 
with  the  other  system. 

a.  IPBLIST  is  always  listening  for  messages  directed  to  System  1. 
When  a message  is  received,  it  is  loaded  in  a common  area  and  IPBPROC  is 
awakened  to  begin  processing  it. 

b.  MSGWAIT  waits  for  messages  forwarded  from  IPBLIST.  It  determines 
whether  the  source  was  NTDS  or  SUS,  forwards  the  NTDS  messages  to  the  eval- 
uation routines,  or  determines  the  confidence  of  the  Speech  Understanding 
Subsystem  (SUS)  phrase  and  sends  it  on  to  IPBPROC. 

c.  IPBPROC  pieces  together  phrases  from  SUS  to  form  a full  message. 

m 

(1)  CHECKMSG  verifies  that  a SUS  message  is  of  high  confidence, 
properly  recognized  by  SUS,  and  is  the  type  of  message  expected. 

(2)  SENDMSG  first  checks  to  see  if  the  SUS  message  is  in  the 
active  scenario  and  if  so,  notifies  the  pilot  model  to  take  the  appropriate 
action. 

d.  IPBLISTN  is  a task  which  listens  for  messages  directed  to  System  2. 
When  a message  is  received,  it  is  loaded  in  a common  area  and  the  resident 
MAIN  task  is  notified  for  processing. 
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User  Interface.  BSC  is  also  responsible  for  processing  console  (CRT-1)  com- 
mands from  the  AIC-LAB  user  to  start,  freeze,  proceed  or  abort  the  scenario 
exercise.  CRTLIST  is  always  listening  for  inputs  from  CRT-1.  When  an  input 
is  received,  it  is  validated  and,  if  correct,  passes  the  request  on  to  the 
resident  MAIN  task  for  processing. 

PILOT  MODEL.  The  pilot  model  simulates  pilot  actions  in  reference  to 
observing  other  aircraft  and  responding  to  commands  issued  by  the  AIC. 
Three  routines  are  involved: 

a.  PLTPER  simulates  the  pilot's  ability  to  observe  aircraft  on  his 
radar  and  within  his  field  of  vision.  It  checks  distances  between  the  CAP 
and  the  bogey  or  strangers,  if  any.  If  the  distance  is  small  enough, 
various  verbal  calls  are  made  depending  on  the  distance. 

b.  PLTMSG  determines  if  a SUS  message  is  suitable  for  the  present 
state  of  the  pilot.  Example:  After  a "radio  check"  pilot  would  be  in  state 
one  and  "Vector  for  bogey"  would  be  suitable,  but  not  the  reverse.  A "say 
again"  is  generated  if  required. 

c.  PLTACT  responds  verbally  to  a SUS  message,  if  it  is  warranted,  as 
well  as  contacting  AIRCHG  with  new  headings  to  alter  the  aircraft's  flight 
if  a command  is  issued  to  do  so. 

The  voice  simulation  is  accomplished  through  a predefined  collection  of 
phrase  elements  (see  Table  3)  stored  on  the  disk  (FRAZ.VO)  and  the  following 
routines.  Note  that  complete  phrases  are  assembled  by  concatenation  of 
these  phrase  elements. 

a.  VSCON  (ASSEMBLER)  places  the  phrase  numbers  which  the  calling  rou- 
tine specifies  (via  formal  input  arguments)  in  a queue. 

b.  VSOUT  processes  the  queued  arguments  by  multi-buffering  from 
FRAZ.VO  to  the  Votrax.  To  accomplish  this,  VSOUT  uses  RDFRAZ  and 
WRFRAZ. 

c.  RDFRAZ  (ASSEMBLER)  reads  the  appropriate  phonemes  of  the  requested 
phrases  number  from  FRAZ.VO. 

d.  WRFRAZ  (ASSEMBLER)  writes  the  phonemes  to  the  Votrax. 

AIRCRAFT  MODEL.  The  AIC-LAB  utilizes  a simple  aircraft  model.  Up  to  ten 
aircraft  can  be  controlled,  and  their  dynamics  are  maintained  in  a core  and 
disk  resident  file  called  the  Track  Data  File  (TDF).  (See  Table  4.)  Two 
routines  maintain  this  file: 

a.  AIRPER  updates  once  a second  the  X-Y  coordinates  of  each  track 
depending  on  its  last  position,  speed  direction,  and  type  of  motion  (turn, 
simple,  orbit,  stationary).  AIRPER  also  writes  a new  copy  to  disk  for  use 
by  CPU-2' s radar  simulation. 
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TABLE  3.  AIC  LAB  PHRASES  ELEMENTS  FOR  VOICE  SYNTHESIS 


Say  Again 
Roger 

Roger,  Out 

Roger,  Stranger  Opening 
Roger,  Rendezvous  Point  Sierra 
Snake 

Snake,  Roger 

Snake,  Roger  Looking 

Snake,  Has  a Visual  on  the  Stranger 

Snake  is  in  a 

Orbit,  Angels  Twenty  Ready  for  Control,  Over 
This  is  Snake,  Point  Whiskey,  Twenty 
Orbit,  Over 
Viper 

Viper,  Roger 
Port 

Port  Hard 

Anchor  Port 

Detach  Port 

Starboard 

Starboard  Hard 

Anchor Star board 

Detach  Starboard 

Contact 

Lost  Contact 

East  Turn 

Tighten  Torn 

Fox  - One 

Fox  - Two 

Breakaway 

Continue 

Judy 

Out 

Tally-Ho 

Vector 

Numbers  0 - 999,999 


1 - 
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TABLE  4.  TRACK  DATA  FILE 


Description 

track  type 

0 track  not  in  use 

1 ownship 

2 CAP 

3 Bogey 

4 Stranger 

5 Friendly 

6 Other 
Motion  model 

1 Simple 

2 Turn 

3 Orbit 

4 Stationary 
Speed  (knots) 

Turn  rate  (degrees/ second) 

Directed  heading  (degrees) 

Heading 

Current  X position  (miles)  - Cartesian 
coordinates 

Current  Y Position  (miles)  - Cartesian 
coordinates 

Speed  in  X direction  (knots) 

Speed  in  Y direction  (knots) 

Altitude  (thousands  of  feet) 

IFF  number  (if  friendly,  0 otherwise) 
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b.  AIRCHG  modifies  the  dynamics  of  a particular  track  (turn,  rate  of 
turn,  new  heading,  orbit,  etc.). 

RADAR  SIMULATION.  Radar  simulation  moves  a sweep  line  across  the  radar 
circle  whose  diameter  represents  64  miles.  The  sweep  runs  at  12  seconds  per 
360°  cycle.  As  it  reaches  the  locale  of  a particular  aircraft,  it  brightens 
the  sweep  and  video  intensities,  and  as  it  moves  away,  the  Intensities  are 
slowly  lowered  to  those  original  states. 

a.  SWPINIT  computes  the  points  of  all  400  radar  sweep  lines  and 
stores  them  in  arrays  SWPX  and  SWPY. 

b.  CYCLIC  draws  sweep  lines  from  ownship  to  successive  sweep  end 
points  every  30  milliseconds  to  simulate  a smooth,  12-second  radar 
sweep. 

c.  GETDATA  computes  new  angles  between  all  videos  and  ownship  every  12 
seconds  using  function  BLMANG.  It  also  reads  the  updates  TDF  from  disk  for 
use  in  radar  videos. 

d.  USEDATA  transfers  the  new  angles  to  active  arrays  for  use  by 
BLOOM. 

e.  BLOOM  increases  the  intensity  of  the  sweep  and  brightly  displays 
the  video  in  its  new  position  when  the  sweep  reaches  the  angles  generated  by 
GETDATA. 

f.  FADE  is  called  once  a second  to  dim  videos  gradually. 

NTDS  SIMULATION.  The  NTDS  functions  which  were  simulated  in  the  AIC-LAB  are 
shown  in  Table  3.  The  symbology  is  generated  via  a hardware  character  gen- 
erator built  into  the  Megatek  display  system.  The  firmware  in  the  PROM  upon 
which  this  generator  operates  was  developed  especially  for  the  laboratory 
model.  A typical  display  is  shown  in  Figure  7. 

a.  BUTTONS  accepts  keyboard  function  codes  or  series  of  codes  and  sim- 
ulates the  appropriate  NTDS  actions  on  the  Megatek  console.  PM&E  and  Teach- 
ing are  notified  of  the  actions  for  evaluation  purposes.  PER4  updates  NTDS 
vehicle  symbol  coordinates  every  four  seconds  and  also  simulates  the  action 
of  an  NTDS  tracker. 

b.  MOVSYM  moves  the  NTDS  symbols  and  their  "speed  leaders."  Bogey 
bearing  and  range  are  displayed  during  engagements. 

c.  M0VH00K  moves  the  hook  symbol  if  it  exists. 

d.  NRBAL  returns  the  track  number  of  the  track  nearest  the  ball  tab. 

e.  TURNOFF  periodically  turns  off  special  Megatek  pictures,  such  as 
the  Illegal  Action  alert. 
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ENABLE  BALL  TAB: 
BALL  TAB  CENTER: 
HOOK: 

SEQ: 

IFF: 

GEOM : 

ORDERSEND: 

POSIT  DATA: 

HDG: 

SPD: 

HDG-  LFT : 

HDG  RT: 

SPD  - UP: 

SPD-  DN 
POS  COR: 

CLEAR : 

SIF: 

FUNCTION  CODE: 

II: 

12: 

363: 

1156: 


TABLE  5.  NTDS  FUNCTIONS 

Enables  ball  Cab  (B/T)  at  last  used  position 

Places  ball  tab  on  ownship 

Hooks  closest  track  within  3 miles  of  B/T 

Places  tracks  on  the  sequence  list  under  close 
control 

Display  mode  2 codes  and  altitude  of  aircraft 
close  to  B/T 

Displays  intercept  geometry  from  hooked  CAP  to 
B/T 

Engages  hooked  CAP  to  B/T  bogey 

Displays  bearing  and  range  from  hook  to  ball  tab 

Displays  heading  of  hooked  track 

Displays  speed  of  hooked  track 

Adjust  hooked  symbol  heading  -5° 

Adjust  hooked  symbol  heading  +5° 

Adjusts  hooked  symbol  speed  up  0. 1 mach 

Adjusts  hooked  symbol  speed  down  0.1  mach 

Moves  hooked  symbol  to  B/T  location 

Clears  NED  windows 

Selected  Identification  Feature 

Enters  the  following  special  functions  from  NED 
windows 

Cancels  engagements 

Changes  PIPIRO  position  to  that  of  B/T 
Places  hooked  track  on  sequence  list 
Enters  the  data  link  status 
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f.  VFBCAL  calculates  Intercept  geometry  (vector  for  bogey). 

g.  GEOM  displays  the  intercept  geometry  and  command  heading. 


TEACHING 

The  Teaching  program  is  intended  to  investigate  and  demonstrate  the 
feasibility  and  validity  of  automatically  presenting  step-by-step  instruc- 
tions to  the  AIC-LAB  user.  The  program  includes  instructions  for  each  of 
the  learning  objectives  of  Scenario  1 and  Scenario  2. 

Instructions  are  presented  to  the  user  ("trainee")  on  CRT-2.  In  addi- 
tion, a brief  clue  or  prompt  is  given  on  the  display  itself.  The  system 
will  only  continue  through  the  exercises  when  correct  actions  are  performed. 
In  the  event  of  an  incorrect  response,  the  system  will  return  the  user  to 
the  point  of  the  error  and  the  instructions  are  repeated.  An  example  of  the 
CRT  presentations  is  shown  in  Figure  8 for  the  Scenario  1 objective,  report- 
ing bogey  bearing  and  range.  (The  numbers  in  the  figure  refer  to  "pages"  on 
the  various  CRT  screens.)  Teaching  is  operational  in  both  Systems  1 and  2. 
The  main  program  is  swapped  in  by  MS/E  when  this  mode  is  selected. 

The  entire  system  relies  on  driver  tables,  one  unique  to  each  learning 
objective.  These  tables  define  step  numbers,  correct  actions,  steps  to  pro- 
ceed to  depending  on  validity  of  the  user's  actions,  whether  to  check  for 
accuracy,  and  whether  some  special  activity  should  accompany  the  particular 
steps.  These  tables,  then,  direct  the  entire  step-by-step  function.  (See 
Table  6.) 


TABLE 

6.  STEP- 

BY-STEP 

DRIVER 

TABLE  OPTIONS 

SCENDF3 

CRT0BJ3 

EVENT 

STEP 

ACTION  If 

GOOD 

BAD 

SPEC  ACTS 

ACCURACY  CK 

1 

1 

10 

2 

1 

92 

0 

2 

2 

10 

3 

2 

0 

0 

3 

3 

3 

4 

5 

1 

3 

4 

4 

45 

0 

1 

2 

0 

5 

5 

45 

0 

1 

2 

0 
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1 #»»**eoGEY  BEARING  4 RANGE***** 


AFTER  THE  CAP  HAS  BEEN  VECTORED  TO  THE  BOGEY,  THE  BOGEY'S  BEARING  AND  RANGE 
FROM  THE  CAP  MUST  BE  REPORTED  TO  THE  PILOT.  IN  ORDER  TO  PROVIDE  ACCURATE 
REPORTS,  YOU  ARE  RESPONSIBLE  FOR  ENSURING  THAT  THE  SYMBOLS  ARE  UP  TO  DATE 
WITH  THE  RADAR  VIDEO  (REMEMBER  WHERE  THE  "REAL"  AIRCRAFT  ARE!).  THE  SYMBOL 
ONLY  REPRESENTS  THE  COMPUTERS  ASSUMED  POSITION.  THE  VIDEO  CAN'T  BE  SEEN  BY 
THE  CO^UTER,  SO  YOU  MUST  TELL  THE  CONPUTER  WHERE  THE  TRACKS  ARE  BY  KEEPING 
THE  SYMBOL  ON  TOP  OF  THE  RADAR  VIDEO. 

WHEN  YOU  BEGIN  THIS  EXERCISE: 

> THE  CAP  SYMBOL  HAS  BEEN  BUILT 

> THE  CAP  4 BOGEY  ARE  ENGAGED 

> VECTOR  FOR  BOGEY  HAS  ALREADY  BEEN  TRANSMITTED 

> BOTH  SNAKE  4 BOGEY  ARE  ON  THE  SEQUENCE  LIST 


DEPRESS  NEW  LINE  TO  CONTINUE. 


RECALL  THAT  A SYMBOL  IS  UPDATED  BY: 


* PLACING  THE  TRACK  IN  CLOSE  CONTROL  VIA  THE  SEQ  BUTTON  OR  BALL 
TAB/HOOK  PROCEDURE 

* MOVING  THE  BALL  TAB  TO  THE  CENTER  OF  THE  FRONT  LEADING  EDGE  OF  THE 
VIOEO 

* DEPRESSING  POS  COR  (POSITION  CORRECTION) 

REMEMBER  THAT  ACCURACY  IS  MAXIMIZED  BY  PERFORMING  THIS  SEQUENCE  JUST  AS  THE 
RADAR  PASSES  THE  TARGET. 


DEPRESS  NEW  LINE  TO  CONTINUE. 

3 

REPORT  THE  BOGEY'S  BEARING  AND  RANGE  BY: 

> UPDATING  THE  CAP'S  POSITION,  IF  NEEDED. 

> UPDATING  THE  BOGEY'S  POSITION,  IF  NEEDED. 

> SEQUENCING  TO  THE  CAP. 

> INTERPRETING  BOGEY'S  BEAR  I NG(XXX)  AND  RANGE  (YY)  FROM  THE  PPIRO. 

> TRANSMITTING  THIS  INFORMATION:  "BOGEY  XXX, YYP". 

4 

THAT  IS  CORRECT! 

THIS  PROCEDURE  SHOULD  BE  PRACTICED  UNTIL  IT  BECOMES  ALMOST  MECHANICAL. 


DO  YOU  DESIRE  A REPEAT? STRIKE  YES  OR  NO. 

5 

YOUR  REPORT  WAS  NOT  AS  ACCURATE  AS  IT  COULD  BE. 

DOUBLE  CHECK  TO  MAKE  SURE  THAT  THE  SYMBOLS  AND  VIDEOS  COINCIDE.  THE 
ACCURACY  OF  YOUR  REPORTS  ARE  CHECKED  AGAINST  THE  "REAL"  AIRCRAFT  POSITIONS 
(RADAR  VIDEO);  NOT  THE  NTDS  SYMBOL  POSITIONS. 


WE  RECOMMEND  THAT  YOU  TRY  THIS  PROCEDURE  OVER. 

DO  YO'i  DESIRE  A REPEAT? STRIKE  YES  OR  NO. 

6 


Figure  8.  Teaching  Presentation  for  Bogey  Bearing  and  Range 


'V  : :: 
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The  tables  are  created  by  an  offline  support  program.  The  principal 
teaching  routines  are  described  below. 

a.  MAIN,  which  consists  of  the  main  programs  for  CPU-1  and  CPU-2, 
opens  files,  creates  tasks,  and  calls  initialization  routines. 

b.  TEACH  uses  the  instructions  from  the  driver  table  to  determine 
which  step  to  proceed  to  depending  on  the  validity  of  the  student's  actions. 

c.  NEXT  retrieves  the  stop  instructions  stored  in  the  driver  tables, 
and  stores  it  in  a common  area  for  System  1 routines  to  access. 

d.  EVALUATE  checks  the  specific  action  performed  by  the  AIC  with  the 
anticipated  correct  action.  It  informs  TEACH  of  its  findings  (good  or  bad). 
EVALUATE  also  directs  special  activities  and  accuracy  checking  when 
requested  to  do  so. 

e.  CHEKIT  handles  accuracy  checking  for  range,  bearing,  speed,  and 
command  heading.  CHEKIT  then  informs  TEACH  of  its  findings. 

f.  SPECIAL  is  a "catch-all"  subroutine  to  handle  specific  activities 
such  as  restarts,  accepting  any  action  until  correct  action  occurs,  etc. 

g.  RESTART  redefines  and  reinitializes  files  in  CPU-1  when  the  AIC 
requests  a repeat  of  a teaching  objective. 

h.  YANK  displays  text  information  on  the  CRT  as  a guide  to  the  stu- 
dent's activities  for  each  teaching  step. 

i.  YANK1  displays  on  the  Megatek  console  a brief  version  of  the  text 
displayed  by  YANK. 

j.  SETUP  redefines  and  reinitializes  Megatek  picture  and  variables  for 
restarts . 

PERFORMANCE  MEASUREMENT  AND  EVALUATION  (PM&E) 

In  addition  to  the  Teaching  mode,  the  user  may  enter  a Freeze  and  Feed- 
back mode  and  a Practice  mode.  These  modes  of  operation  are  performed  by 
the  PM&E  programs,  and  support  only  Scenarios  1 and  2. 

The  Freeze  and  Feedback  mode  offers  the  student  a practice  environment 
in  which  he  can  request  system  monitoring  of  selected  AIC  learning  objec- 
tives. If  the  system  encounters  a major  error,  it  freezes  and  notifies  the 
student  of  the  error.  At  this  point,  the  student  can  correct  the  problem 
and  continue  with  the  exercise.  Note,  however,  that  this  mode  gives  no 
feedback  except  in  the  case  of  an  error  and  only  if  the  error  occurs  in  one 
of  the  selected  training  areas.  The  Practice  mode  presents  the  student  with 
an  opportunity  to  operate  on  a given  scenario  without  interruption.  His 
actions  are  monitored  and  graded  with  respect  to  procedural  correctness, 
accuracy,  and  timing  as  defined  by  AIC  standards  of  operation,  but  there  are 
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no  Interruptions  in  the  event  of  an  error.  In  both  modes,  the  student  is 
presented  with  an  evaluation  report  (see  Figure  9)  at  the  end  of  the 

exercise.  As  shown,  the  report  provides  a historical  assessment  of  the 
student's  strengths  and  weaknesses  in  the  various  learning  objectives,  and 

also  a detailed  explanation  of  errors  made  in  the  just-completed  exercise. 

These  error  messages  are  identical  to  those  given  during  run-time  if  the 
Freeze  and  Feedback  options  are  selected. 

This  Performance  Measurement  algorithm  may  be  characterized  by  the 
following  attributes.  Time  restrictions  among  events  can  be  enforced. 

Sequences  of  events  can  occur  cyclicly.  Constraints  about  the  order  of 

events  can  change  dynamically.  Any  number  of  external  actions  san  be  taken 
when  an  event  occurs.  Complicated  event-order  constraints  can  be  enforced. 
For  example,  if  events  A and  B are  to  precede  event  C,  the  chain  pointers 
for  both  A and  B should  include  another  "internal"  event  D,  whose 

count-field  is  initially  two.  When  both  A and  B have  occurred,  D's  count 

will  have  been  decremented  to  zero,  causing  D to  occur.  Thus,  the  relation 

"D  must  precede  C”  will  be  equivalent  to  "both  A and  B must  precede  C".  In 
general,  the  relations  “X  must  precede  Y"  and  "X  cannot  occur  after  Y"  may 
exist  for  any  X and  Y defined  as  actual  external  events,  or  internally  in 
terms  of  other  events. 

Because  the  PM&E  algorithms  implemented  in  the  AIC  laboratory  model  may 
be  of  general  interest,  the  following  paragraphs  describe  it  in  greater 
detail. 

THEORETICAL  DISCUSSION.  In  the  following  discussion,  capital  letters  (A,  B, 
...)  designate  numbers  representing  events.  External  events  are  those  given 
to  PM&E  by  the  event  preprocessing  module.  Internal  events  are  created 
within  PM&E  itself  in  response  to  the  occurrence  of  ocher  events.  Events 
were  presented  in  Table  2. 

PM&E  can  enforce  two  relations  between  events: 

A < B;  that  is,  event  A must  precede  event  B,  and 

A i>B;  that  is,  event  A cannot  occur  after  event  B; 

where  A and  B can  be  internal  or  external. 

For  example, 

"the  fighter  was  located"  < "the  radio  check  was  given"; 

"contact  confirmed"  > "pilot  gave  an  incorrect  contact  call." 

An  internal  event  A can  be  defined  to  have  occurred  if  m out  of  n 
events  Bj  , B2 , . . . , Bn  have  or  have  not  occurred.  The  notation  for 
this  is: 

A = (m:  [-1]  BL , [-«]  B2,  ...  [I]  Bn). 


37 


— 


PI  kf  OkAAMCE  fcliOkl  I Ok  NOW!  1 1 


Figure  9.  Student  Evaluation  Report 
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Some  specific  cases  are: 

A = (3:Bj,  B2,  B3),  A has  occurred  when  Bj , B2,  and  B3  have 
occurred. 

A=  (l:Bj^,  B2),  A occurs  when  Bj  or  B2  occurs. 

A=  (4:B),  A occurs  when  B has  occurred  4 times. 

As  (2:Bj,  B2 , - B3),  A occurs  when  Bj  and  B2  have  occurred, 
and  B3  has  not  occurred. 

In  the  definition,  A = (m:Bj,  B2 , . . . ) , where  m Is  called  the  count, 
which  Is  used  as  follows:  when  an  event  B^  occurs  which  is  In  the 
definition  of  A,  m is  set  to  infinity  if  B^  was  preceded  by  a "-1"  in  A's 
definition;  otherwise  m is  decremented  by  one.  A occurs  when  m becomes 
zero.  Note  that  m should  be  initially  set  to  the  number  of  events  that  must 
occur,  as  shown  in  the  previous  examples. 

A list  of  actions  ("special-actions")  can  be  taken  when  an  event 
occurs.  Typical  examples  are: 

a.  Create  or  change  < and  -i>  relations 

b.  Start/stop/ reset  outside  clocks 

c.  Set/ reset  "occurred"  status  of  events 

d.  Change  the  count-fields  (m)  of  events 

e.  Change  special-action  list  for  an  event 

f.  Change  definition  of  an  internal  event 

g.  Perform  accuracy-checking  on  numbers 

h . End  the  run 


Proper  choice  of  special  actions  will  allow  sequences  of  events  to 
occur  cyclicly,  time  constraints  to  be  enforced,  relations  among  events  to 
change  dynamically,  and  so  on. 

The  data  structure  and  algorithm  which  support  the  PM&E  are  described 
in  the  following  paragraphs. 


! 

I 

• ; 
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Data  Structure: 

There  Is  an  array  of  information  records  about  each  event  A^  in  the 
following  format: 


record  — 


OCC 

CNT 

BE 

NAE 

CP 

SAP 

— for  event  A^; 


OCC  — occurred  status  for  this  event 
CNT  — present  count  m for  this  event 
BE  — event  that  must  precede  this  one  (can  be  null) 

NAE  ~ event  this  cannot  occur  after  (can  be  null) 

CP  — pointer  to  list  of  internal  events  whose  definitions  involve  Aj^ 
(can  be  null) 

SAP  — pointer  to  list  of  special-actions  to  be  taken  when  A^  occurs 
(can  be  null) 


NAVTRAEQUIPCEN  78-C-0053-1 

The  CP  field  points  to  a list  of  Internal  events  to  be  updated.  In  the 
following  format: 


i i 

i i 

i i 


records  for  events 
to  be  updated. 


i i 


(array  CHN ) 


Note:_A_Indlcates  End  of  File. 


record  [ ] EVT 


[ *i  ] — was  Bj  preceded  by  a "V  in  the  definition  of  A^  If  so, 
it  was  not  to  have  occurred. 

EVT  — event  number  for  internal  event  Bj. 
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The  SAP  field  points  to  a list  of  special-actions  to  be  taken,  in  the 
following  format: 


OP  ~ operation-code  for  action  to  be  taken  (opcode). 

<parameters>  — counts,  event-numbers,  etc.,  associated  with  the 
special-action. 

There  is  also  a stack  of  records  of  events  which  are  queued  for  occur 
rence.  Each  record  is  in  the  same  format  as  those  in  arrav  CHN. 
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stack  is  initially  empty; 
when  an  event  occurs 
begin 

push  event  onto  stack; 

if  its  CP  field  is  not  null  then 

begin 

push  its  list  of  events  in  chain  onto  the  stack; 
do  the  same  for  each  new  entry  on  the  stack; 

end; 

repeat 

pop  record  for  event  A^  off  the  stack; 
if  [ -i  ] field  is  true  then 
A j ' s CNT  field  :=*oo 

else 

Ai's  CNT  field  : * * - 1 ; 
if  A^'s  CNT  - 0 then  |event  A^  is  ready  to  occur} 
begin 

if  A^'s  BE  not  null  then  {check  event  preceding  A^  } 
if  event  BE  has  not  occurred  then 
signal  error; 

if  A^'s  NAE  not  null  then  {event  Aj  can't  occur  after} 
if  event  NAE  has  occurred  then 
signal  error; 
if  A^'s  SAP  not  null  then 
do  special-actions; 

A^ ' s OCC  :=true;  {event  A^  has  just  occurred} 

end; 

until  stack  is  empty; 

end. 
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IMPLEMENTATION.  PM&E  uses  a number  of  files  for  Initializing  arrays, 
recording  run-performance,  etc.  See  Figure  10.  The  principal  PM&E  files 
are: 

a.  PMTXT.OX:  Test  describing  each  event,  plus  some  special  texts 

b.  PMEVNT.OX:  Read  into  EVINF  array.  Contains  for  each  event: 

(1)  Special  action  pointer  (may  be  null) 

(2)  Bit  for  unconditional  special  action 

(3)  Event  that  must  have  occurred  before  this  one 
("before-error");  may  be  null 

(4)  Bit  indicating  that  the  "before-error"  is  minor  or  major 

(5)  Event  this  one  cannot  occur  after  ("after-error");  may  be  null 

(6)  "After-error"  is  minor/major  bit 

(7)  Present  count  field 

(8)  Chain  pointer 

c.  PMEVT2.0X:  Read  into  EVINF2.  Learning-objective  number  associated 

with  each  event 


d.  PMDECK.OX:  Read  into  DECKS.  Contains  lists  of  actions  to  be 

executed  upon  each  event,  if  any 

e.  PMCLK.OX:  Read  into  CLKINF.  Contains  initial  values  of  clocks, 

and  the  events  they  cause  to  occur 


f.  PMCHN.OX:  Read  into  CHN.  Contains  list  of  events  to  update  upon 

an  event,  if  any 


(X  = scenario  id:  1 or  2) 


The  PM&E  files  are  created  by  off-line  programs;  their  content  is  shown 
(for  Scenario  2)  in  Tables  7 through  12. 

Routine  PMSPER  decrements  the  counts  of  all  clocks  with  non-zero  counts 
once  every  second.  When  a clock's  count  reaches  zero,  its  associated  event 
occurs  via  a call  to  EVENT.  Subroutine  EVENT  translates  an  event  of  the 
form  (source,  message)  into  a single  event  number.  This  is  given  as  a 
parameter  to  subroutine  PMSEVNT , the  front-end  of  the  PM&E  module.  PMSEVNT 
checks  the  viability  of  an  event.  The  event  which  just  occurred  is  first 
pushed  onto  a stack,  defined  as  array  STK.  If  its  chain-painter  is  not 
null,  the  events  in  CHN  starting  at  the  pointer's  indicated  position  are 
also  pushed.  Then,  for  each  event  on  the  stack,  that  event's  count-field  is 
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TABLE  7.  PMTXT  FILE,  SCENARIO  2 


PM TXT  SCENARIO  TO  * 2 

CVENT  TEXT 

1 THE  RAO  10  CHECK  WAS  GIVEN 

2 THE  VECTOR  FOR  BOGEY  WAS  GIVEN 

3 THE  BOGEY'S  BEARING  AND  RANGE  WERE  GIVEN 

A THE  COGEY’S  TRACK  AND  GROUNDSPEED  WERE  GIVEN 
3 THE  STRANGER'S  BEARING  AND  RANGE  WERE  GIVEN 

6 THE  STRANGER’S  TRACK  ANO  GROUNOSPEEO  WERE  GIVEN 

7 A STRANGER  OPENING  REPOR T WAS  GIVEN 

0 . A BOGEY  JINKING  LEFT  REPORT  WAS  GIVEN 

7 A 80GEY  JINKING  RIGHT  REPORT  WAS  GIVEN 

10  A NEGATIVE  CONTACT  REPORT  WAS  GIVEN 

11  THE  PILOT'S  CONTACT  REPORT  WAS  CONFIRMED 

12  AFTER  A STRANGER  WAS  REPORTED.  A SWEEPS  ELAPSED 

13  AFTER  A STRANGER  WAS  REPORTED.  5 SUEEPS  ELAPSED 

1 A AFTER  THE  PILOT  HAD  A VISUAL.  AO  SECONDS  ELAPSED 

13  AFTER  THE  VECTOR  FOR  BOGEY  WAS  GIVEN,  3 SECONDS  ELAPSED 

16  A3  SECONDS  ELAPSED 

17  1 MINUTE  ELAPSED 

18  AFTER  THE  CAP  WAS  LOCATCD , 30  SECONDS  ELAPSCD 

1?  AFTER  THE  CAP  WAS  LOCATED.  AS  SECONDS  ELAPSED 

20  100  SECONDS  ELAPSED 

21  2 MINUTES  ELAPSED 

22  AFTER  THE  BOGEY  WAS  DETECTED,  20  SECONDS  ELAPSED 

23  AFTER  THE  BOGEY  WAS  DETECTED,  3 SWEEPS  ELAPSCD 

2 A AFTER  THE  VECTOR  FOR  BOGEY  WAS  GIVEN,  15  SECONDS  ELAPSED 

25  AFTER  THE  VECTOR  FOR  80GEY  WAS  GIVEN.  20  SECONDS  ELAPSED 

26  ONE  SWEEP  ELAPSED 

27  AFTER  THE  BOGEY  JINKED,  20  SECONDS  ELAPSED 

28  AFTER  THE  BOGEY  JINKED,  30  SECONDS  ELAPSCD 

27  AFTER  THE  BOGEY  JINKED.  30  SECONDS  ELAPSED 

30  AFTER  THE  BOGEY  JINKED,  AO  SECONDS  ELAPSED 

31  THE  PILOT  GAVE  A LOST  CONTACT  REPORT 

32  THE  EXCERCIZE  STARTED 

33  THE  BOGEY  WAS  DETECTED 

3 A THE  BOGEY  JINKED  LEFT 

33  THE  BOOEY  JINKED  RIGHT 

36  THE  PILOT  GAVE  A CORRECT  CONTACT  CALL 

37  THE  PILOT  GAVE  AN  INCORRECT  CONTACT  CALL 

38  THE  CAP  WAS  LOCATED 

3?  THE  CAP  SYMBOL  WAS  BUILT 

AO  THE  TRACKS  WERE  CNGAGED 

A1  THE  PILOT  GAVE  A JUDY  CALL 
A2  A JINK  DIRECTION  WAS  REPORTED 
A3  THE  BOGEY  JINKED 

AA  AFTER  THE  VECTOR  FOR  BOGEY  WAS  GIVEN.  A SWEEPS  ELAPSED 

A3  AFTER  THE  VECTOR  FOR  BOGEY  WAS  GIVEN,  3 SWEEPS  ELAPSED 

A6  3 SWEEPS  ELAPSED 

A 7 A BEARING  AND  RANGE  REPORTS  WERE  GIVEN  ON  THE  BOGEY 

AG  THE  PILOT  GAVE  A CONTACT  CALL 

A9  A RESPONSE  TO  A CONTACT  CALL  WAS  GIVEN 

30  A STRANGER  CLOSED  WITHIN  8 MILES  OF  THE  CAP 

51  A STRANGER  CLOSED  WITHIN  7 MILES  OF  THE  CAP 

32  THE  PILOT  HAO  A VISUAL  ON  THE  STRANGER 

53  THE  STRANGER  WAS  OPENING 

3A  THE  STRANGER  WENT  OUTSIDE  1G  MILES  OF  THE  CAP 
53  A STRANGER  REPORT  WAS  GIVEN 

36  AFTER  THE  PILOT  GAVE  A CONTACT  CALL,  IS  SECONDS  ELAPSED 

57  AFTER  THE  PILOT  GAVE  A CONTACT  CALL,  26  SECONDS  ELAPSED 

3G  AFTER  THE  PILOT  GAVE  A LOST  CONTACT  REPORT,  10  SECONDS  ELAPSED 

59  AFTCR  THE  PILOT  GAVE  A LOST  CONTACT  REPORT.  15  SECONDS  ELAPSCD 

60  3 SWEEPS  ELAPSED 

61  6 BEARING  AND  RANGE  REPORTS  WCRE  GIVEN  ON  THE  STRANGER 
42  THE  PILOT  GAVE  A TALLY  HO 

63  THE  STRANGER  CLOSED  WITHIN  10  MILES  OF  THE  CAP 
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TABLE  8.  SPECIAL  TEXTS  FOR  SCENARIO  2 

PMTXT : SPECIAL  TEXT  PORTION 

TEXT  ft  TEXT 

0 THE  BEARING  WAS  OVER  7 OEGREES  OFF 

1 THE  RANGE  WAS  OVER  3 MILES  OFF 

2 THE  SPEED  WAS  OVER  .2  MACH  OFF 

3 THE  COMMAND  HEADING  WAS  OVER  7 DEGREES  OFF 

4 THE  HEADING  WAS  OVER  7 DEGREES  OFF 

5 THE  GEOGRAPHIC  DIRECTION  WAS  OVER  40  DEGREES  OFF 

6 THE  BEARING  WAS  3-7  DEGREES  OFF 

7 THE  RANGE  WAS  2-3  MILES  OFF 

0 THE  SPEED  WAS  .1-.2  MACH  OFF 

9 THE  COMMAND  HEADING  WAS  3-7  DEGREES  OFF 

10  THE  HEADING  WAS  3-7  DEGREES  OFF 

11  THE  GEOGRAPHIC  DIRECTION  WAS  30-40  DEGREES  OFF 
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PNEVT2 

EVENT 


TABLE  9.  PMEVT2  AND  PMEVNT 

AND  PflEVNT 

LO  ACTPTR  ALWAYS  NAGBEF 


FILES  FOR  SCENARIO  2 


HAGNAFT 

BEF 

NAFT 

CNT 

CHAIN 

0 

3? 

1 

0 

2 

0 

1 

0 

0 

2 

0 

33 

41 

0 

7 

0 

33 

41 

0 

2 

0 

0 

0 

0 

13 

0 

0 

0 

0 

11 

0 

S3 

0 

0 

2 

0 

0 

35 

0 

1 

0 

0 

34 

0 

1 

a 

48 

36 

0 

18 

a 

40 

37 

0 

13 

0 

6 

0 

0 

2 

0 

6 

0 

0 

2 

□ 

0 

□ 

0 

□ 

l 

40 

0 

0 

2 

l 

38 

0 

0 

2 

l 

30 

0 

0 

2 

l 

3? 

0 

0 

2 

0 

3? 

a 

0 

2 

1 

1 

0 

0 

2 

a 

1 

0 

0 

2 

i 

2 

0 

0 

2 

0 

2 

0 

0 

*> 

l 

3 

0 

0 

2 

0 

3 

0 

0 

2 

1 

0 

0 

0 

3 

1 

42 

0 

0 

2 

0 

42 

0 

0 

2 

1 

4 

0 

□ 

2 

0 

4 

0 

0 

2 

0 

a 

0 

0 

2 

0 

0 

0 

0 

2 

0 

0 

a 

0 

2 

0 

0 

0 

0 

? 

0 

0 

0 

0 

7 

0 

0 

0 

0 

13 

0 

0 

0 

0 

13 

0 

0 

38 

0 

dm 

0 

30 

3? 

0 

2 

0 

1 

0 

0 

o 

0 

0 

0 

0 

2 

0 

43 

0 

1 

2 

1 

0 

0 

1 

0 

4 

0 

4 

*> 

0 

4 

0 

5 

2 

0 

47 

0 

5 

l 

0 

0 

4 

a 

0 

0 

1 

2 

a 

43 

0 

l 

2 

0 

55 

0 

0 

n 

0 

55 

0 

0 

2 

0 

0 

0 

0 

•> 

0 

0 

0 

0 

2 

0 

7 

0 

0 

*» 

0 

63 

52 

1 

■■5 

0 

4? 

0 

0 

2 

0 

4? 

0 

0 

o 

0 

3 

0 

0 

n 

0 

3 

0 

0 

2 

□ 

61 

0 

0 

-y 

0 

0 

0 

4 

0 

0 

0 

0 

2 

0 

0 

0 

0 

-> 

| 


I 
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TABLE  10.  PMDECK  FOR  SCENARIO  2 

PNDECK 

ENTRY  OPCODE  FORMAT 


i 

1 

3 

CLKNUM 

= 1 

CLKVAL  = 

45 

•J 

1 

3 

CLXNUH 

= 2 

CLKVAL  ’ 

60 

3 

1 

3 

CLKNUM 

« 5 

CLKVAL  = 

100 

4 

t 

3 

CLKNUN 

“ 6 

CLKVAL  ’ 

120 

5 

0 

2 

APTR  - 

0 

EVNT2  * 

0 

6 

0 

2 

APTR  = 

0 

EVNT2  = 

0 

7 

1 

3 

CLKNUM 

= 3 

CLKVAL  = 

30 

a 

1 

3 

CLKNUN 

- 4 

CLKVAL  » 

45 

9 

0 

2 

APTR  * 

0 

EVNT2  » 

0 

10 

0 

2 

APTR  = 

0 

EVNT2  = 

0 

11 

4 

1 

CHBIT  * 

0 

EVNT1  « 

33 

EVNT2 

S 

2 

12 

0 

2 

APTR  ’ 

0 

EVNT2  * 

0 

13 

0 

2 

APTR  * 

0 

EVNT2  = 

0 

1'. 

4 

1 

CHBIT  =* 

0 

EVNT1  « 

2 

GVNT2 

a 

3 

15 

4 

1 

CHBIT  = 

0 

EVNT1  * 

2 

EVNT2 

r- 

4 

16 

1 

3 

CLKNUfl 

* 7 

CLKVAL  » 

20 

17 

1 

3 

CLKNUfl 

= 8 

CLKVAL  * 

36 

13 

0 

2 

APTR  * 

0 

EVNT2  ■ 

0 

19 

6 

r> 

APTR  » 

2 

EVNT2  « 

0 

20 

1 

3 

CLKNUM 

« 0 

CLKVAL  - 

5 

21 

1 

3 

CLKNUM 

= 9 

CLKVAL  * 

15 

22 

l 

3 

CLKNUM 

’ 10 

CLKVAL  » 

20 

23 

1 

3 

CLKNUM 

=•  11 

CLKVAL  « 

12 

24 

5 

2 

APTR  = 

64 

EVNT2  ■ 

2 

25 

0 

2 

APTR  » 

0 

EVNT2  « 

0 

26 

3 

1 

CHBIT  - 

1 

EVNT1  » 

26 

EVNT2 

* 

0 

27 

1 

3 

CLKNUM 

* 11 

CLKVAL  « 

12 

20 

0 

2 

APTR  = 

0 

GVNT2  ■ 

0 

29 

0 

2 

APTR  = 

0 

EVNT2  » 

0 

30 

6 

2 

APTR  » 

4 

EVNT2  » 

0 

31 

0 

2 

APTR  » 

0 

EVNT2  ■ 

0 

32 

0 

2 

APTR  « 

0 

EVNT2  ■ 

0 

33 

1 

3 

CLKNUM 

« 12 

CLKVAL  ■ 

20 

34 

1 

3 

CLKNUM 

» 13 

CLKVAL  * 

30 

35 

1 

3 

CLKNUM 

- 14 

CLKVAL  • 

30 

36 

t 

3 

CLKNUM 

= 15 

CLKVAL  » 

40 

37 

3 

1 

CHBIT  = 

1 

EVNT1  « 

4 

EVNT2 

a 

0 

30 

3 

1 

CH8IT  » 

1 

EVNT1  - 

8 

GVNT2 

a 

0 

39 

3 

1 

CHBIT  « 

1 

EVNT1  - 

9 

EVNT2 

* 

0 

40 

3 

1 

CHBIT  « 

1 

EVNT1  * 

42 

EVNT2 

a 

1 

41 

0 

2 

APTR  = 

0 
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TABLE  10.  PMDECK  FOR  SCENARIO  2 (CONT) 
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TABLE  11.  PMCLK  FILE  FOR  SCENARIO  2 
PflCLtf 

CLOCK  VALUE  EVENT 

0 0 15 

1 0 16 


0 17 
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updated.  If  the  countfield  is  now  zero,  the  event  is  defined  to  have 
occurred,  thereby  checking  for  "before-error"  and  "after-error"  conditions. 
SPCACT  is  called  if  the  event's  special  action  pointer  is  not  null  and  no 
major  errors  occurred.  If  any  errors  occurred,  minor  or  major,  the  error 
handler  (ERRHANDL)  is  called. 

SPCACT  is  given  a special-action  pointer  to  a location  in  DECKS  con- 
taining the  first  of  possibly  several  special  actions  to  be  executed.  Each 
location  contains  an  action-number  (opcode)  field  and  some  parameter  fields. 
The  possible  actions  are: 

a.  Set  clock  N to  value  T 

b.  Enable/Disable  the  occurrence  of  an  event 

c.  Change  a relation:  (A  and  B are  event  numbers) 

(1)  A must  occur  before  B 

(2)  A cannot  occur  after  B 

d.  New  special-action  pointer  for  Event  A is  P 

e.  Upon  event  A,  before-  or  after-error  is  minor  or  major 

f.  Special-action  is  unconditional  for  event  A 

g.  End  the  exercise  normally  (wakes  up  .MAIN) 

h.  Call  KLUDGE  for  accuracy-checking 

KLUDGE  checks  for  accuracy  of  numbers  recognized  by  SUS.  They  are 
command-headings,  bearings  and  ranges,  and  headings  and  speeds.  If  a number 
is  grossly  inaccurate,  it  is  a major  error;  if  somewhat  so,  a minor  error. 
The  error-handler  is  called  for  both  kinds  of  errors. 

The  error-handling  routine,  ERRHANDL,  records  the  detected  error  in 
<Name>  .EL,  the  student's  error-log.  If  the  error  was  major,  and  the  freeze 
and  feedback  option  which  the  event  (causing  the  error)  corresponds  to  is 
set,  then  an  error-message  is  composed  in  the  form:  [the  text  for  the  event 
causing  the  error]  [special  texts]  [and]  [text  for  another  event  that  was  or 
was  not  to  have  occurred].  The  system  is  then  frozen  and  the  error  message 
is  displayed  on  CRT-2.  Otherwise,  the  run  proceeds  normally. 

When  a run  has  ended  normally,  the  main  program  calls  PMSREP  to  grade 
the  student's  performance  for  each  of  the  learning  objectives  in  the 
scenario.  The  grading  rules  are,  for  each  learning  objective: 

a.  any  major  error:  weak, 

b.  >N  minor  errors:  weak, 
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SECTION  V 

SYSTEM  UTILIZATION 


INTRODUCTION 

The  AIC  laboratory  model  was  exposed  and  used  by  three  AIC  instructors 
(one  retired)  and  three  subjects  not  previously  familiar  with  operational 
AIC  responsibilities.  Unfortunately,  technical  difficulties  prevented  the 
complete  integration  of  speech  recognition  capabilities  into  the  remainder 
of  the  system  in  time  to  thoroughly  evaluate  and  exercise  all  aspects  of  all 
scenarious  for  all  users. * Nevertheless,  considerable  experience  was 
gained  with  the  system  and  much  was  learned  even  in  these  preliminary 
sessions.  Logicon  intends  to  continue  using  the  model  in  the  near  future  to 
investigate  and  refine  the  functional  characteristics  of  AIC  training 
systems. 

The  following  subsections  highlight  comments  and  suggestions  made  rela- 
tive to  the  features  implemented  in  the  laboratory  model.  In  addition,  they 
describe  the  lessons  learned  through  the  design,  implementation,  and  test 
phases  of  the  project. 

SIMULATION 

Radar  and  NTDS  provided  relatively  high-risk  or  questionable  areas  to 
be  addressed  by  the  model.  How  effective  would  commercial  systems  be  in 
simulating  the  radar/symbology  presentations?  How  much  effort  would  it  be 
to  emulate  the  required  NTDS  functions? 

The  high  resolution,  vector-stroke  graphics  techniques  produce  a very 
"clean"  display.  The  radar  videos  used  in  the  laboratory  model  were  con- 
sidered too  crisp  and  clear;  rather,  they  should  look  more  like  a "blob"  of 
brightened  phosphor.  The  orientation  of  the  video  should  be  perpendicular 
to  the  radar  sweep.  The  video  must  be  generated  more  realistically  by  the 
sweep.  The  entire  scope  requires  more  clutter  (additional  aircraft,  weath- 
er, land  mass,  etc.)  to  be  realistic.  Although  a clean,  crisp  display  is 
adequate-in  fact  beneficial-in  the  early  phases  of  training,  instructors 
agree  that  the  AIC  must  become  used  to  working  with  the  more  realistic, 
cluttered,  systems  before  moving  into  live  air  control.  How  realistic  is 
still  undefined. 


1 See  NAVTRAEQUIPCEN  78-C-0044-1.  Briefly,  the  major  problems  were  achiev- 
ing good  accuracy  on  phrases  ending  in  bearing  or  heading  information,  such 
as  "bogey  tracking  217,"  and  developing  the  reference  data  for  recognition 
of  connected  digits.  Additional  speech  stylizations,  namely  pausing  before 
the  three-digit  sequence  and  developing  a dynamic  programming  recognition 
algorithm,  were  suggested  as  solutions  to  the  first  problem.  Additional  R&D 
will  be  required  to  ease  the  burden  of  creating  the  LCSR  data  base.  Alter- 
natively, other  methods  for  performing  LCSR  should  be  considered. 


NAVTRAEQUIPCEN  78-C -0053-1 


The  emulation  of  NTDS  functions  was  relatively  straightforward  once 
they  were  defined.  The  problem  was  In  specifying  the  button  actions  in 
sufficient  detail  to  provide  accurate  simulation.  For  example,  does  "enable 
Ball  Tab”  cause  the  ball  tab  to  appear  at  ownshlp,  the  center  of  the  screen, 
or  at  its  last  location?  Every  seemingly  insignificant  detail  must  be 
defined  In  order  for  the  emulation  to  retain  face  validity. 

The  utilization  of  the  commercial  graphics,  keyboard,  and  joystick  for 
NTDS  promulgated  much  discussion  concerning  the  NTDS  console(s)  to  be  used 
in  the  experimental  prototype  training  system  as  well  as  in  the  ultimate 
operational  AIC/ASAC  trainer.  Often  contradictory  comments  made  by  the  AIC 
instructors  and  others  exposed  to  the  system  included: 

a.  Operational  gear  (UYA-4  and  Operational  NTDS  programs)  is  an  abso- 
lute requirement  in  the  training  environment. 

b.  Development  of  a look-alike,  synthetic  console  would  be  adequate 
for  early  stages  of  training. 

c.  A synthetic  console  would  be  useful  only  if  it  could  accept  live 
radar  and  radios. 

d.  Emulating  NTDS  programs  is  not  feasible  because  they  are  always 
changing. 

e.  New  consoles  are  also  being  developed,  and  hence  one  must  take  a 
long  and  studied  look  at  which  console  to  emulate  in  developing  a synthetic 
console. 

f.  A transfer  of  training  could  occur  on  a totally  commercial 
training-equipment-based  system. 

Clearly,  the  question  of  operational  versus  simulation  is  a complex  and 
hotly  debated  issue.  No  one  seemed  to  doubt  that  the  cost  savings  would  be 
substantial  if  the  simulated  console  and  program  were  used.  But  training 
effectiveness  and  maintaining  operational/simulation  functional  compata- 
bility  are  not  so  easily  agreed  upon.  As  will  be  suggested  in  the  next 
section,  this  would  appear  to  be  a valid  and  fruitful  research  issue  for  the 
experimental  prototype  system. 

TEACHING 

A step-by-step  instructional  approach  was  viewed  as  effective.  The 
following  comments  typify  those  made  during  utilization  of  the  laboratory 
model . 


a.  The  system  must  provide  flexibility  within  the  teaching  mode.  The 
student  should  be  free  to  perform  the  utilitarian  NTDS  functions  in  addition 
to  those  requested  by  the  step-by-step  instructions. 
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b.  Host  errors  made  by  the  students  are  founded  on  his  Inability  to 
accurately  track  the  symbols  on  video.  Early  exercises  need  to  concentrate 
on  keeping  symbols  on  the  video. 

c.  The  computer  instructions  need  to  emphasize  the  job  more  than  the 
buttons.  For  example,  the  student  should  first  learn  that  he  must  let  the 
NTDS  computer  know  which  aircraft  he  intends  to  control;  secondly,  he  should 
be  taught  that  this  is  done  by  building  a CAP  symbol  during  the  check-in 
procedure;  third,  he  should  be  taught  the  step-by-step  procedure  to  be 
followed  in  order  to  build  a CAP  symbol  on  this  console  with  this  program. 

d.  Highly  synthetic,  unrealistic  scenarios  can  be  effective  teaching 
tools.  For  example,  shipboard  personnel  often  use  the  NTDS  programs  (with 
symbols  only)  for  proficiency  training. 

e.  The  transitions  from  element  to  element  in  the  teaching  programs 
must  be  accomplished  smoothly  and  quickly. 

f.  One  of  our  major  concerns  centers  around  motivating  the  system 
users.  Little  will  be  accomplished  if  the  presentations  cannot  hold  the 
student’s  interest  or  create  the  desire  to  acquire  more  knowledge.  It 
appears  that  the  majority  of  personnel  receiving  AIC  training  is  gradually 
shifting  to  "short  term"  individuals,  both  in  terms  of  time  spent  in  the 
Navy  as  well  as  time  left  before  discharge.  This  adds  an  additional  burden 
and  should  be  strongly  considered  when  planning  all  phases  of  the 
experimental  prototype. 

A problem  encountered  throughout  the  laboratory  model  effort  was  confu- 
sion about  the  goals  of  the  program.  This  was  especially  evident  when 
discussing  the  Teaching  mode.  The  model's  Teaching  programs  were  not  spec- 
ifically designed  to  teach  a "student"  to  use  the  model.  Step-by-step 
instructions  are  just  one  element  of  an  automated  training  system.  The  fact 
that  we  did  not  (and  probably  could  not)  actually  fully  train  anyone  with 
the  model  is  not  a disparaging  commentary.  The  purpose  was  to  investigate 
and  demonstrate  how  a complex  skill  task  might  be  addressed  in  an  automated 
training  system. 

PERFORMANCE  MEASUREMENT  AND  EVALUATION 

The  Freeze  and  Feedback  mode  represented  a demonstration  and  investiga- 
tion or  an  errorless  learning  strategy  in  which  the  user  is  not  allowed  to 
proceed  if  he  makes  a major  error.  A complete  evaluation  of  this  and  the 
Practice  mode  was  not  possible  because  of  the  problem  encountered  with  the 
speech  recognition.  Nevertheless,  the  following  observations  were  made: 

a.  Error-reports  should  include  more  detail.  For  example,  they  should 
describe  performed  button  sequences  versus  correct  sequences,  or  the  prob- 
able cause  of  inaccurate  advisories  (tracking,  etc.). 

b.  Run-time  feedback  might  include  judicious  use  of  voice  generation. 


NAVTRAEQU IPCEN  78-C -0053-1 


c.  Standards  must  be  adjusted  to  meet  the  expected  skills  of  the 
student.  For  example,  an  accuracy  of  +5°  may  be  fine  as  an  end-of-course 
standard,  but  is  it  probably  too  tight  in  the  beginning. 

The  whole  issue  of  standards  and  their  measurement  provided  consider- 
able learning  opportunities.  The  performance  measurement  system  needed  to 
support  AIC  training  is  very  much  unlike  that  of  other  controller  tasks  pre- 
viously addressed,  e.g.,  GCA.  AIC  performance  must  be  measured  not  only  in 
terms  of  accuracy  and  timeliness,  but  also  in  procedure.  The  resulting 
software  is  more  akin  to  a procedures  monitor  than  has  been  previously 
required. 

The  laboratory  system  also  hinted  that  the  arbitrary  accuracy  standards 
(e.g.,  +3°,  +2  miles)  may,  in  fact,  be  highly  unrealistic.  This  is  an  area 
rich  in  research  and  development  opportunities,  since  there  have  never  been 
any  studies  on  AIC  performance  using  their  operational  console  as  there  have 
been  with  pilots,  for  example.  A definitive  assessment  of  these  issues  will 
probably  require  data  extraction  and  reduction  using  operational  or  (non- 
existant  to-date)  simulated  NTDS  consoles  and  programs.  At  this  point,  it  is 
doubtful  that  anyone  really  knows  how  accurate  even  the  best  AIC  .has  been. 

Finally,  it  became  clear  that  the  standards  must  depend  on  the  range 
between  CAP  and  bogey.  If  the  hostile  aircraft  is  forty  miles  from  the  CAP, 
say,  the  bearing  surely  does  not  require  the  same  accuracy  as  if  they  were 
ten  miles  apart.  Whereas  these  observations  may  seem  self-evident,  in  point 
of  fact  they  were  generated  from  observation  and  utilization  of  the  AIC 
laboratory  model. 

SCENARIO  3 

The  teaching  and  performance  measurement  functions  were  not  implemented 
for  Scenario  3.  The  system  simulation  did  support  it.  However,  due  to  time 
constraints,  we  did  not  exercise  this  scenario.  The  results,  conclusions 
and  recommendations  made  in  this  report  were  consequently  derived  from  and 
validated  against  the  tactical  job  of  the  AIC  in  conducting  CAP-to-bogey 
intercepts.  But  insofar  as  the  performance  measurement  and  evaluation 
features  of  the  system  were  only  implemented  in  Scenarios  1 and  2,  there  is 
minimal  impact  on  the  project's  goals  because  Scenario  3 was  not  exercised. 


NAVTRAEQUIPCEN  78-C-0053-1 
SECTION  VI 

CONCLUSIONS  AND  RECOMMENDATIONS 

GENERAL  REMARKS 

The  development  and  utilization  of  an  AIC  laboratory  model  was  a worth- 
while and  fruitful  effort.  Much  was  learned  about  AIC  instructional  fea- 
tures, simulation  requirements,  performance  measurement,  and  speech  under- 
standing. As  a high-risk  developmental  research  effort,  the  model, 
understandably,  was  not  entirely  free  from  its  share  of  problems.  The 
companion  studies  in  speech  recognition  affected  the  utilization  and  full 
exploitation  of  the  model  adversely.  Fortunately,  however,  the  experiences 
with  the  speech  understanding  programs  will  save  time  and  dollars  later  when 
the  experimental  prototype  is  being  designed  and  developed.  The  AIC  task  is 
a complex  one.  In  this  study,  we  learned  both  what  to  do  and  what  not  to 
do.  Taken  in  total  context,  we  conclude  that  automated  AIC  training  is  both 
viable  and  effective. 


CONTINUING  RESEARCH  INTEREST 

This  laboratory  effort  has  had  interesting  spinoff  benefits.  In  addi- 
tion to  supporting  the  front-end  analysis  of  an  automated  prototype  training 
system,  it  has  suggested  specific  points  of  research  interest  during  that 
prototype  effort. 

JOB  VERSUS  OPERATIONS.  AIC  training  has  traditionally  concentrated  on  the 
mechanics  of  console  functions  needed  to  support  the  AIC's  jobs.  This 
approach  places  heavy  emphasis  on  the  specific  console  and  operational  NTDS 
program.  As  new  consoles  and  programs  are  released  to  the  fleet,  expanded 
or  increased  training  is  required. 

Because  of  the  inevitability  of  changes  in  the  console  and  program, 
however,  other  approaches  should  be  studied.  We  suggest  that  the  experi- 
mental prototype  system  investigate  the  effectiveness  of  a training  program 
which  emphasizes  the  job  first,  but  integrates  simulated  console  operations 
later.  Such  a system  would  not  only  teach  the  basic  skills,  but  it  would 
also  teach  the  capability  to  transfer  those  skills  to  another  piece  of 
operational  hardware.  The  student  must  understand  that  he  is  being  taught 
to  be  flexible,  to  expect  change  and  to  fit  each  specific  task  or  exercise 
into  the  overall  job  of  the  AIC. 

SIMULATED  CONSOLE.  Beacuse  of  the  Interest  and  controversy  surrounding  use 
of  a simulated  (look-alike)  NTDS  console  and  emulated  NTDS  program,  we  sug- 
gest that  the  experimental  prototype  system  address  this  issue  as  well. 
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RECOMMENDED  TRAINING  SYSTEM  SPECIFICATIONS 

The  following  subsections  delineate  the  functional  capabilities  which  we 
recommend  for  consideration  in  the  development  of  an  experimental  prototype 
system.  These  recommendations  are  based  upon  studies  conducted  during  this 
front-end  analysis  project. 

TRAINING  FUNCTIONS.  The  Experimental  Prototype  AIC  Training  System  (AIC- 
PROTO)  should  train  student  controllers  to  prepare  them  for  live  air  inter- 
cept control.  The  training  system  should  teach  the  knowledge  (jobs)  and  the 
necessary  skills  (controls)  to  conduct  basic  air  intercepts,  air  combat 
maneuvers,  special  mission  aircraft,  setups,  friendly/ tanker  join-ups,  and 
other  required  tasks.  Table  13  contains  the  learning  objectives  to  be 
addressed . 

Following  an  entry  test  to  verify  appropriate  entry  level,  the  trainee 
should  be  taught: 

a.  To  extract  information  from  an  NTDS  UYA-4-type  device  (e.g.,  bear- 
ing and  range  from  the  interceptor  to  the  hostile  aircraft  target  (bogey), 
bogey  track  and  ground  speed) 

b.  To  use  an  IFF  (UPA-59A)-type  device,  radio-telephone  voice  commu- 
nications, one-  and  two-way  data  links 

c.  To  calculate  setups  for  aircrews  in  a training  environment.  This 
procedure  allows  the  aircrews  to  train  from  a desired  target  aspect  angle 

d.  To  respond  to  real-world  conditions  including  emergency  situations, 
special  mission  aircraft,  jamming,  radar  fades,  land  masses,  splits,  and 
formation  flying 

e.  To  follow  the  aircraft  for  safety  of  flight,  to  avoid  other  air- 
craft and  to  maintain  the  aircraft  in  a desired  area 

f.  To  provide  vectors  and  heading  recommendations  for  friendly/ tanker 
join-ups,  to  vector  to  the  bogey  when  it  appears  the  interceptor  is  on  the 
wrong  target,  and  to  establish  a nearest  collision 

g.  To  coordinate  with  the  Ship's  Weapons  Coordinator  (SWC),  Track 
Supervisor  (TRK  SUP),  and  the  Learning  Supervisor 

A post-test  should  verify  that  the  trainee  can  indeed  perform  the 
established  learning  objectives  addressed  by  the  AIC-PROTO. 
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TABLE  13.  LEARNING  OBJECTIVES  TO  BE  ADDRESSED  BY  AIC-PROTO 


Range  and  bearing  froa 
Interceptor  to  target 


Target  track  and  speed 


Jinking 


NTDS  failure 


Update  TAO/SWC 


Splitting  bogeys 


Composition  and 
formations 


Missions  for  CAPs, 
other  than  Intercepts 
and  engagements 


Jamming  and  Inter- 
ference 

One-  and  two-way  data 
link  operations 

The  training  environ- 
ment 


Friendly  tanker 
Joln-ups 


The  student  will  be  required  to  ensure  that  the  symbols  arc  on  video  prior  to  using 
range  and  bearing  Information.  Although  che  bogey  will  be  tracked  by  ocher  NTDS 
operators  (trackers),  the  AIC  may  update  che  track.  The  Combat  Air  Patrol  (CAP) 
will  be  command  cracked  by  the  NTDS;  che  AIC  will  be  able  to  modify  the  heading, 
speed  and  alcltude  to  conform  to  the  actions  of  che  CAP. 

The  AIC  will  bring  che  bogey  symbol  Into  close  control  and  Interpret  che  bogey 
track  and  ground  speed  froa  the  NTDS  console's  Data  Read  Out  (DRO). 

The  AIC  will  be  able  to  detect  a drastic  change  In  track,  speed  or  altitude  by 
using  che  crack  history  functions  of  NTDS.  The  direction  will  be  easily  dececced, 
while  both  speed  and  altitude  Jinks  will  show  up  as  ground  speed  Jinks. 

The  AIC  will  perform  che  above  Casks  without  the  use  of  che  compucer  program.  The 
AIC  will  continue  Co  give  needed  Information  until  the  program  la  restored. 

The  Tactical  Action  Officer  (TAO)  will  know  the  progress  the  CAP  Is  making,  an 
estimate  as  to  probability  of  making  tha  Intercept  and  the  results  of  che 
Intercept.  The  AIC  will  coordinate  this  Information  through  che  SVC. 

The  AIC  will  obtain  the  bogey's  composition  by  lncerpreclng  the  radar  scope,  from 
crackers  and  ocher  means.  Ac  che  moment  any  separation  Is  detectad  It  will  be 
critical  chat  che  aircrews  are  notified  so  they  can  react. 

The  Interpreting  of  composition  and  formation  will  dictate  the  tactics  the  aircrew 
will  employ.  The  AIC  will  be  alert  to  provide  this  Information  and  any  change. 

Air  Combat  Maneuvering  (ACM)  challenges  che  AIC  to  lncerprec  what  Is  happening  In  a 
dogfight.  Timing,  positioning  cankers,  splltouts,  other  aircraft  Joining  the 
fight,  and  friendly  caver  ace  some  of  tha  areas  AICa  must  learn  to  be  effective 
during  ACM.  Communication  must  be  realistically  caughc  during  multiplane 

engagements. 

Weather  reconnaissance  fllghcs,  where  che  AIC  gives  range,  bearing  and  area  concrol 
Information  co  che  aircrew,  relays  weather  reports  and  assists  In  emergencies. 
Barrier  patrol  and  search- and- rescue  are  other  examples  of  missions  for  purposes 
other  Chan  Intercept  and  engagements. 

The  AIC's  Job  Is  che  same  during  adverse  conditions.  The  student  will  be  taught  Co 
do  what  ha  can,  however,  co  continue  Co  give  che  bast  Information  available. 

The  AIC  must  be  able  to  lnldace  data  link  operations,  send  targec  and  orders  co 
the  aircraft  and  Interpret  che  crack  Information  sent  back  down. 

The  aircraft  requires  setups  of  specific  target  aspect  angles  to  allow  training 
from  desired  posldons.  For  disengagements,  a recommended  breakaway  heading  will 
be  necessary. 

\ low-risk  missed  Intercept  for  low  fuel  CAP  will  be  caught  by  turning  the  canker 
and  allowing  the  CAP  Co  Join  on  him.  ^ 
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SYSTEM  OPERATION  CONCEPTS.  The  training  sessions,  taken  as  a whole,  should 
provide  for  the  application  of  behavioral  technology  to  promote  learning, 
individualized  instruction,  carefully  structured  around  levels  of  achieve- 
ment, and  a highly  automated  multiphased  approach  should  lead  the  way  to  an 
effective  training  system. 

AIC-PROTO  should  provide  a training  environment  which  places  the 
responsibility  for  learning  on  the  student.  The  system  operation  concept  is 
shown  in  Figure  11.  Although  no  system  can  force  learning,  AIC-PROTO  should 
challenge  the  student  to  achieve  obtainable  short-range  goals.  These  goals, 
or  levels  of  achievement,  should  gradually  introduce  new  learning  objec- 
tives, progressing  from  easy  to  hard,  simple  to  complex.  Levels  of  achieve- 
ment should  put  the  emphasis  on  achievement  and  motivation. 

AIC-PROTO  should  adapt  to  the  individual  needs  of  the  trainee,  teaching 
only  what  the  trainee  needs,  as  long  as  is  necessary.  The  aircraft's  ipeed, 
antenna  rotation  rate,  the  skill  of  the  pilot/ tracker , the  amount  of  mater- 
ial, and  the  number  of  repetitions,  etc.,  each  should  be  adjustable  to  fit 
the  particular  needs  of  the  trainee. 

By  maximizing  the  level  of  automation,  the  system  should  minimize 
requirements  of  the  instructor  during  the  teaching,  grading  and  critiquing 
phases  of  training.  AIC-PROTO  should  provide  standards,  objective  grading 
on  the  learning  objectives,  and  criteria  for  advancement. 

AIC-PROTO  might  provide  optional  warmup  drills,  selectable  from  a menu 
of  learning  skills  previously  addressed.  A multiphased  approach  could  then 
introduce  new  learning  objectives: 

a.  Teaching  and  Validation  mode:  While  voice  data  are  collected  and 
validated,  new  material  could  be  introduced  in  a step-by-step  fasnion,  with 
AIC-PROTO  demonstrating  the  correct  method  of  performance  and  giving  the 
trainee  a clear  picture  of  his  tasks.  AIC-PROTO  could  then  allow  the  train- 
ee to  correctly  perform  the  new  task  while  the  system  monitors  performance. 
This  should  ensure  that  the  trainee  learns  the  material  correctly  the  first 
time.  The  trainee  should  be  able  to  challenge  the  learning  objective  before 
going  into  the  freeze  and  feedback  mode. 

b.  Freeze  and  Feedback  mode:  AIC-PROTO  could  integrate  the  new  mater- 
ial with  the  previously  covered  material,  freezing  on  errors  of  the  new 
material  only.  Feedback  could  be  given  and  the  trainee  could  correct  the 
mistake. 


c.  Grading  mode:  AIC-PROTO  could  provide  the  trainee  an  opportunity 
to  practice  the  material  presented  thus  far,  giving  results  and  recommenda- 
tions for  more  practice,  remedial  training  or  advancement. 

d.  Annotated  Replay  mode:  AIC-PROTO  could  (optionally)  replay  previ- 
ous practice  runs  (either  in  their  entirety  or  only  selective  portions), 
critiquing  in  detail  the  student's  performance. 
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Figure  11.  Prototype  System  Operation  Concept 
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e.  Remedial  Training  mode:  Based  upon  the  system's  ability  to  diag- 
nose trainee  weaknesses,  remedial  training  should  be  provided.  Remedial 
training  categories  are: 

(1)  Knowledge  tasks,  for  which  AIC-PROTO  should  restate  the  proce- 
dures, time  windows,  or  statement  of  appropriate  rules. 

(2)  Simple  skill  tasks,  for  which  the  system  should  go  back  to  the 
freeze  and  feedback  mode  where  the  learning  objective  was  introduced. 

(3)  Complex  skill  tasks,  for  which  it  should  re-instruct  the 
student  using  a different  instructional  approach. 

OPERATIONAL  SHIPBOARD  EQUIPMENT  SIMULATIONS.  The  AIC-PROTO  should  provide 
realistic  radar  (video)  presentations;  NTDS  functions,  symbology,  and  data 
read  outs;  IFF  information;  data  link  and  other  communications  methods.  A 
careful  preliminary  analysis  of  system  simulation  requirements  has  identi- 
fied the  following  minimum  necessary  functions. 

Radar  Simulation. 


a.  A sweep  rate  variable  from  one  to  five  revolutions  per  minute  (RPM) 

b.  Controlled  fades  to  ensure  dead  reckoning  by  the  student 

c.  Aircraft  video  size  variable  to  represent  an  SPS  48-type  radar 

d.  A maximum  of  twenty-four  videos  with  a selectable  size  of  small, 
medium  and  large 

e.  IFF  associated  with  select  videos 

f.  Gate  to  determine  the  IFF  challenge  area,  with  the  size  of  the  gate 
selectable  on  the  training  device 

g.  Jamming,  noise  and  land  masses 
NTDS  Console  Functions  Simulation. 


a.  The  quick  action  buttons  for  the  AC  mode 

b.  The  number  entry  controls  and  display 

c.  Required  displays  in  the  data  read  outs  (DROs) 

d.  The  fixed  action  buttons  including  drop  track,  enter  mode  and 
radar,  radar  select,  enter  offset,  intensity  controls  and  range  scale, 
selection  from  16,  32  and  64  miles 
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e.  The  track  ball  and  controls  for  the  ball  tab 

f.  Radio  channel  and  controls 

g.  Three  intercommunications  channels  and  controls 

h.  A plotting  scope  which  rotates  to  compensate  for  magnetic  variation 
NTDS  symbology  simulation. 

a.  Ten  friendly,  four  CAP,  six  hostile,  four  unknown  air  symbols  to 
include  speed  leaders,  assignment  and  engagement  bars 

b.  Four  friendly  and  four  hostile  surface  symbols 

c.  Balltab,  hook,  TACAN  station,  ownship,  geometry  lines  between  sym- 
bols, a fly-to-point  capability,  and  a command  tracking  function 

d.  The  plan  position  indicator  read  out  (PPIRO)  which  displays  infor- 
mation on  the  scope  of  the  track  in  close  control.  (For  example,  range  and 
bearing  information  will  appear  by  an  engaged  track.) 

e.  Twenty  lines  drawn  to  be  fixed  geographically  or  slaved  to  a sym- 
bol. Individual  lines  may  be  dropped  without  affecting  the  others. 

IFF  Simulation.  A UPA-59A  type  IFF  unit  to  include  the  following  job 
tasks: 

a.  Assist  in  tracking  friendly  aircraft  using  IFF 

b.  Locate  friendly  aircraft  using  IFF 

c.  Identify  one  friendly  aircraft  from  another  using  IFF 

d.  Determine  height  on  friendly  aircraft  using  IFF 

e.  Provide  positive  identification  using  IFF  and  asociated  PPI  presen- 
tations that  include: 

(1)  Bracket  pulse 

(2)  Identification  pulse 

(3)  Emergency  pulse 

(4)  Mode  4 

(5)  Gate  pulse 

The  required  switches,  lights  and  alarms  should  also  be  functional. 

AIRCRAFT,  ENVIRONMENT,  AND  ASSOCIATED  PERSONNEL  SIMULATION.  The  prototype 
system  should  simulate  the  other  factors,  which  taken  together  with  the 
aforementioned  shipboard  systems,  will  provide  the  effective  AIC  simulation 
environment. 
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Aircraft  Performance  Simulation. 


a.  Turn  rate:  1.5,  3,  4.5  and  6 degrees  per  second 

b.  Speed:  0.5  to  2.5  mach.  Acceleration  and  deceleration  to  repre- 
sent standard  fighter  performance. 

c.  Altitude:  variable  from  0 to  50,000  feet.  Rate  of  climb  and 

descent  to  represent  standard  fighter  performance. 

Environment  Simulation.  Wind  should  affect  the  aircraft  tracks.  Wind 
should  be  programmable  from  scenario  control  and  manual  input.  Wind  can 
range  from  0 to  100  knots.  Each  5000  feet  of  altitude  can  have  a different 
wind. 

CAP/Bogey  Pilot  Simulation.  A pilot  model  should  react  to  a given  situation 
under  three  modes  of  operation:  manual,  controlled  and  responsive. 

a.  The  manual  mode  should  allow  the  aircraft  to  follow  only  the 
trainee's  commands. 

b.  The  controlled  mode  should  respond  to  predefined  scenarios. 

c.  The  responsive  mode  should  react  to  the  trainee's  information  and 
recommendations.  Feedback  will  be  given  from  the  weapon  system  which  is 
representative  of  an  F4-type  system  with  a degrading  factor  to  allow  optimum 
use  of  the  AIC.  This  mode  will  be  extremely  effective  in  preparing  an  AIC 
for  live  air  control.  Three  degrees  of  efficiency  should  be  selectable: 
weak,  normal,  and  strong. 

Tracker  Simulation.  A tracker  model  should  react  to  the  trainee's  accuracy 
when  calling  range  and  bearing.  The  more  accurate  the  trainee  is,  the  bet- 
ter the  tracking.  If  the  trainee  is  weak  in  providing  accurate  range  and 
bearing  calls,  the  hostile  symbols  should  not  be  tracked  accurately. 

Communications  Simulation.  The  internal  communications  between  the  AIC,  SWC 
and  the  TRK  SUP  should  be  simulated  and  reactive.  When  SWC  will  assign 
targets  to  the  AIC  by  voice,  the  symbol  alerts  should  reflect  the  actions. 
The  AIC  should  be  able  to  coordinate  with  the  TRK  SUP  on  tracking  and  radar 
performance  problems.  One  channel  should  allow  the  Learning  Supervisor  to 
communicate  with  the  trainee. 

The  external  voice  communication  between  the  CAP  and  AIC  should  func- 
tion through  a radio  control  panel  and  footkey.  Voice  simulation  during 
ACMs  should  be  particularly  realistic  to  provide  effective  training. 

The  data  links,  both  one-  and  two-way,  should  simulate  tactical  situa- 
tions. Voiceless  data  link  hops  should  be  available  for  training. 
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AUTOMATED  SPEECH.  The  automated  training  system  should  monitor  the  control- 
ler's verbal  behavior.  The  system  should  understand  the  standard  AIC  trans- 
missions from  the  trainee  and  react  appropriately.  Moreover,  since  the 
system  acts  as  the  aircrew  and  other  personnel,  it  should  produce  all  trans- 
missions from  the  aircrew,  SWC  and  TRK  SUP,  as  well  as  simulate  the  student 
in  demonstrations  and  exercise  replays. 

The  automated  speech  recognition  system  should  allow  the  trainee  to 
input  verbal  information  into  the  training  system.  The  AIC-PROTO  should 
interpret  the  predefined  vocabulary,  react  if  needed  and  determine  if  the 
transmission  was  needed  and  met  the  required  standards.  Speech  recognition 
would  thus  facilitate  the  automated  instructional  features. 


The  trainee  issues  two  types  of  transmissions:  orders  and  information. 

The  CAP  model  should  react  to  the  situation  or  to  the  AIC's  orders.  In  a 
tactical  situation  the  CAP  model  should  react  to  the  AIC  heading/speed 
information  as  advisory  information.  The  training  environment  would  require 
the  CAP  and  bogey  models  to  react  to  the  AIC  recommendations.  Speech  recog- 
nition chould  provide  the  basis  for  this  simulation. 

i.'h  i primary  use  for  automated  speech  generation  should  be  to  simulate 
the  aircrew's  voice.  It  is  important  to  associate  the  video  on  the  scope 
with  the  aircrew.  If  voice  generation  isused  for  too  many  things,  it  would 
be  hard  for  the  trainee  to  make  the  necessary  correlation.  One  distinctive 
voice  should  simulate  the  aircrew,  with  another  voice  simulating  the  AIC 
during  demonstrations  and  replays.  Introductory  presentations  and  any  other 
uses  (except  the  aircrew  simulation)  could  use  the  AIC  voice. 

NAVTRAEQUI PCEN ' s research  interests  in  the  utilization  of  the  automated 
speech  technologies  in  training  systems  design  will  dictate  other  functional 
requirements  of  the  system,  such  as  data  extraction  and  recognition  accuracy 
evaluations . 

INSTRUCTOR  MODEL.  A reasonable  design  goal  for  the  experimental  prototype 
system  Is  a fully  automated  system  that  would  relegate  to  the  computer  the 
exercise  selection,  performance  measurement,  and  student  critiquing  func- 
tions normally  performed  by  an  AIC  instructor.  This  objective  translates  j 

into  several  systems-level  functional  requirements  which  are  briefly  out- 
lined below. 

The  heart  of  an  automated  training  system  is  the  decision  logic  of  the 
automated  instructor.  Algorithms  within  the  model  select  what,  when,  and 
how  the  various  learning  objectives  are  presented  to  the  trainee.  The 
instructor  model  should  present  the  material,  measures  performance,  provides 
feedback,  diagnoses  problem  areas,  and  recommends  subsequent  training 
modalities . 
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Present  Training  Material.  The  system  should  provide  the  functional  capa- 
bilities to: 

a.  Teach  underlying  concepts  and  job  tasks  through  textual,  pictorial, 
and  verbal  presentations. 

b.  Demonstrate  in  show-and-tell  fashion  how  these  jobs  are  implemented 
with  the  consoles  available  to  the  AIC. 

c.  Interact  with  the  trainee  using  computer-assisted  instruction 
(CAI)-like  functions  to  verify  the  student's  understanding  of  his  job.  It 
should,  however,  avoid  trick  questions,  deliberate  misleads,  or  ambiguous 
propositions. 

d.  Provide  remedial  training  to  students  with  identified  weaknesses  in 
specific  learning  objectives. 

Measure  Trainee  Performance.  The  system  should  provide  a performance 
measurement  capability  which  can  detect  errors  of  the  following  types: 

a.  Procedural  errors:  The  AIC  took  some  action  or  issued  a command  or 
advisory  when  he  should  not  have  done  so. 

b.  Timeliness  errors:  The  AIC  failed  to  take  an  action  or  issue  a 

command  or  advisory  when  he  should  have  done  so. 

c.  Frequency  errors:  The  AIC  failed  to  provide  an  advisory  as  often 
as  he  should  have. 

d.  Accuracy  errors:  The  information  related  in  the  command/advisory 
was  not  accurate  relative  to: 

(1)  True  aircraft  positions,  and/or 

(2)  NTDS  provided  information. 

The  AIC  training  problem  poses  the  challenge  of  developing  a uniquely 
flexible  performance  measurement  capability.  Although  many  of  the  basic 
skills,  such  as  reporting  target  track  and  speed,  are  relatively  straight- 
forward; other  areas  such  as  ACM  and  setups  require  more  sophisticated 
schemes.  Using  setups  in  the  training  environment  as  an  example,  recall 
that  the  trainee  controls  the  movement  of  both  aircraft  (the  CAP  and  bogey). 
Using  a grease  pencil,  the  trainee  calculates  the  desired  target  aspect 
angle  and  plots  (on  the  scope  face)  the  planning  bearing  and  the  fighter's 
and  bogey's  headings.  After  acquiring  the  desired  separation,  he  turns  the 
aircraft  for  the  intercept.  The  algorithm  should  tolerate  errors  that 
could,  in  fact,  jeopardize  the  entire  run.  The  instructor  model  should  be 
able  to  grade  the  student  for  any  given  situation,  even  if  the  situation  is 
unsatisfactory;  the  trainee  should  be  graded  on  the  given  situation. 
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Provide  Feedback.  The  Instructor  model  of  the  prototype  system  should 
provide  feedback  to  both  the  training  manager  (Instructor)  and  the  trainee. 
In  terras  of  Instructor  feedback,  It  should: 

a.  Provide  various  levels  of  information  (under  instructor  control)  on 
an  individual  trainee's  performance.  This  feedback  should  include  go/no-go 
decisions  at  the  terminal  objective  level  on  the  one  hand,  down  to  detailed 
quantitative  information  at  the  enabling  objective  level,  on  the  other 
hand. 


b.  Enable  the  instructor  to  monitor  or  replay  specific  runs  or  exer- 
cises with  annotated  comments  directed  specifically  to  the  instructor.  An 
annotated  hardcopy  graphic  representation  of  an  air  control  exercise  would 
be  highly  desirable.  This  capability  would  enable  the  instructor  to  confer 
with  the  student  about  specific  problems  or  strengths  at  their  leisure,  thus 
adding  considerably  to  the  level  of  instructor  automation  and  freedom,  which 
is  a primary  design  goal  of  the  system. 

c.  Present  an  overview  of  the  trainee's  progress  through  a level  of 
achievement  and/or  the  entire  course.  Information  on  the  amount  of  t~me 
(percentage  and  absolute)  spent  in  remedial  training  would  be  of  benefit  to 
both  the  instructor  and  training  system  designer. 

d.  Provide  information  on  a class  of  trainees.  This  information, 
together  with  the  trainee  specific  data,  would  provide  the  instructor  with 
an  overview  of  the  student's  performance  in  relation  to  other  students. 
Moreover,  this  type  of  information  would  support  the  evaluation  of  the 
automated  training  system  itself. 

e.  Present  the  results  of  trainee  evaluation.  This  information  should 
include,  as  a minimum,  an  indication  of  areas  of  strengths  and  weaknesses  of 
the  trainee.  Recommendations  and  rationale  for  advancement,  additional 
practice,  or  remedial  training  should  be  provided. 

f.  Format  all  instructor  feedback  in  a way  that  facilitates  quick  com- 
prehension by  the  instructor.  Maximum  use  should  be  made  of  graphic  presen- 
tations such  as  curves  and  bar  charts. 

In  terms  of  trainee  feedback,  the  instructor  model  should: 

a.  Selectively  freeze  upon  detection  of  errors,  providing  instruc- 
tional feedback  to  the  student  concerning  the  error  and  recommended  correc- 
tive action. 

b.  Reinforce  correct  behavior  by  providing  positive  feedback  when  a 
trainee  has  demonstrated  the  proper  behavior. 

c.  Provide  end-of-run,  end-of-level , end-of-day,  and  end-of-course 
information  at  various  (and  selectable)  levels  of  detail.  Textual,  graphic, 
and  voice  feedback  methods  should  each  be  considered  as  appropriate. 
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d.  Provide  an  annotated  replay  capability  of  the  previously  run  exer- 
cise to  facilitate  automated  trainee  coaching. 

Diagnose  Trainee  Strengths  and  Weaknesses.  An  important  function  of  the 
automated  training  system  is  to  properly  infer  (from  data  provided  by  the 
performance  measurement  function)  the  relative  strengths  and  weaknesses  of 
the  trainee.  In  the  prototype,  "relative"  should  refer  to: 

a.  The  trainee's  current  performance  relative  to  the  absolute  behav- 
ioral standards  determined  by  an  AIC  training  task  analysis 

b.  The  trainee's  current  performance  relative  to  his  current  point  in 
the  training  syllabus 

c.  The  trainee's  current  performance  relative  to  other  students  who 
have  been  trained  (satisfactorily  or  not)  by  the  prototype 

Because  it  is  an  experimental  prototype,  the  functional  requirements 
imposed  upon  this  aspect  of  the  instructor  model,  i.e.,  diagnosis  of 
strengths  and  weaknesses,  should  emphasize  flexibility  and  ease  of  modifica- 
tion. A simple  table-look-up  scheme  should  be  considered.  For  each  (quan- 
titative) performance  measurement  variable  relating  to  the  learning  object- 
ives, a range  of  values  should  be  established  (initially  guessed  at,  but 
subsequently  determined  empirically).  This  range  of  values  should 
categorize  the  trainee's  performance  as  indicative  of  a behavioral  strength, 
borderline,  or  a weakness.  This  construct  would  provide  a functional  basis 
for  the  experimentation  with  the  training  system  to  impact  this  aspect  of 
the  instructor  model.  The  result  of  this  performance  evaluation,  as  with 
the  performance  measurement,  should  provide  the  material  for  the  trainee  and 
instructor  feedbacks  discussed  earlier. 

Direct  the  Training  Syllabus.  A final  functional  requirement  imposed  upon 
the  instructor  model  should  be  to  marshall  the  system's  simulation,  voice 
technologies,  and  instructional  features  and  construct  a syllabus  which  will 
enable  the  trainee  to  learn  the  required  material  at  a challenging  but 
achievable  pace.  More  specifically,  the  system  should: 

a.  Provide  a pre-test  to  validate  that  prospective  trainees  meet  the 
minimum  entry-level  qualifications. 

b.  Provide  an  ordered  sequence  of  instructional  material  including 
typical  scenarios  and  exercises  which  will  form  the  basis  for  teaching  the 
AIC  tasks  and  skills. 

c.  Develop  decision  algorithms  to  determine  when  the  trainee  should 
advance  through  the  syllabus,  or  indeed  be  directed  to  previously  covered 
(remedial)  a»ercises.  These  algorithms  should  be  automated  and  adaptive, 
but  the  ins '-.rue  tor  should  always  be  given  the  opportunity  to  override  the 
decisions  of  the  computer  model. 
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d.  Provide  a post-test  or  final  examination  to  validate  that  the 
trainee  is  prepared  to  control  live  aircraft  and  has  met  the  standards  for 
behavior  defined  for  the  system.  Deficiencies  on  the  part  of  the  trainee 
should  be  noted  with  a cross-reference  to  specific  tasks  and  skills  and  to 
that  portion  of  the  syllabus  wherein  the  skill  was  taught. 
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